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1.  Introduction  and  Executive  Summary 

1.1  The  Promise  of  Finite  Element  Analysis 

The  finite  element  method  has  become  a  standard  for  design  analysis  of  aerospace 
structures.  It  is  an  irreplaceable  tool  for  all  aerospace  organizations,  and  for  the  Air 
Force  itself.  While  emphasis  has  shifted  somewhat  toward  commercial  software  pack¬ 
ages,  most  aerospace  firms  also  devote  significant  resources  to  in-house  finite  element 
software  development,  evaluation,  and  training.  Finite  element  analysis  promises 
faster  and  more  accurate  analysis,  more  efficient  designs,  and  less  dependence  on 
costly  and  time-consuming  tests. 


1.2  The  Promise  Unfulfilled 

The  prevalence  of  finite  element  analysis  in  many  industries  is  testimony  to  its  ef¬ 
fectiveness.  Yet  in  some  ways  the  promise  of  the  method  remains  unfulfilled.  Con¬ 
siderable  resources  are  devoted  to  finite  element  models,  and  the  return  on  these 
resources  is  not  what  it  should  be.  Many  models  die  a  premature  death  because  they 
were  not  adequately  documented,  verified,  publicized,  archived,  or  made  available  to 
organizations  that  could  have  made  use  of  them. 

Within  the  Air  Force,  this  problem  was  perceived  by  Dr.  V.  B.  Venkayya,  Dr. 
James  Olsen,  and  others  in  the  Structures  Division  of  the  Flight  Dynamics  Laboratory 
who  have  been  leaders  in  developing  methods  of  structural  analysis  and  optimization 
for  many  years.  Briefly,  the  problem  is  that  the  Air  Force  is  getting  nowhere  near  full 
value  for  the  finite  element  models  that  are  developed  either  directly  or  by  contractors. 
Generally  speaking,  contractors  are  not  required  to  deliver  the  models  they  develop  as 
a  part  of  their  aircraft  structural  design  analysis  work.  There  are  many  circumstances 
in  which  the  Air  Force  could  benefit  from  having  these  models  after  the  aircraft  have 
been  put  into  service.  When  such  circumstances  arise,  Air  Force  personnel  have 
no  good  choices.  They  either  develop  models  themselves  (labor-intensive),  pay  a 
contractor  to  develop  a  model  (expensive  and  difficult  to  fund),  or  do  without  (losing 
valuable  opportunities). 

The  idea  behind  this  SBIR  program  is  that  these  problems  might  be  remedied 
by  establishment  of  a  centralized  operation  dedicated  to  identifying,  collecting,  doc¬ 
umenting,  verifying,  storing,  modifying,  and  disseminating  finite  element  models  of 
Air  Force  aircraft.  In  addition,  a  specification  is  proposed  that  could  be  used  for 
future  procurement  programs  so  that  contractors  were  required  to  deliver  models  to 
the  Air  Force.  The  specification  would  primarily  address  documentation  and  format 
requirements.  A  draft  Mil-Standard  appears  in  Appendix  B  of  this  report. 


1.3  Goals 


The  Phase  I  feasibility  study  was  intended  to  do  the  following: 

1.  Evaluate  current  practices  in  finite  element  analysis  among  selected  Air  Force 
organizations. 

2.  Outline  a  military  standard  that  could  eventually  be  used  to  specify  require¬ 
ments  for  delivery  of  finite  element  models  by  aircraft  development  contractors 
to  the  Air  Force. 

3.  Propose  a  plan  of  operation  for  an  Air  Force  center  where  models  would  be 
collected,  documented,  verified,  modified,  stored,  retrieved,  and  distributed, 
with  emphasis  on  potential  cost  savings. 

4.  Investigate  supporting  software  that  could  be  used  in  the  operation  of  this 
Center. 

The  Phase  II  goals  were  as  follows: 

1.  Develop  and  demonstrate  database  software  for  finite  element  models. 

2.  Draft  a  prototype  Mil-Standard  for  delivery  of  finite  element  models. 

3.  Produce  a  Plan  of  Operation  for  an  Air  Force  Finite  Element  Model  Center. 

1.4  Findings  of  Phase  I 

The  findings  of  the  Phase  I  study  may  be  summarized  briefly  as  follows: 

1.4.1  Survey  Confirms  FDL  Suspicions 

The  Air  Force  is  not  getting  full  benefit  from  the  finite  element  models  of  aircraft 
structures  that  are  developed  by  contractors.  The  perceptions  of  FDL  engineers  and 
others  that  this  is  so  are  supported  by  the  survey  reported  in  Appendix  A  and  by 
the  authors’  personal  experience.  This  is  partly  a  management  problem  and  partly  a 
technical  problem.  That  is,  there  are  few  if  any  organized  procedures  for  acquiring, 
documenting,  modifying,  and  distributing  these  models.  This  report  shows  that  these 
problems  are  costing  the  Air  Force  a  lot  of  money  and  many  lost  opportunities. 

1.4.2  Lack  of  Model  Delivery  Requirements:  the  Consequences 

Contractors  are  not  currently  required  to  deliver  the  finite  element  models  they  de- 
ve’op  while  designing  aircraft.  Our  survey  showed  several  cases  where  Air  Force 
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organizations  needed  models  that  perhaps  should  have  been  delivered  when  the  air¬ 
craft  were  procured.  In  these  cases  they  either  paid  for  another  model  to  be  created, 
or  did  without.  There  have  probably  been  many  cases  where  Air  Force  organizations 
recognized  a  need  for  a  model  but  immediately  dismissed  the  idea,  believing  that  the 
obstacles  to  finding  or  creating  the  model  they  needed  were  too  great. 

1.4.3  Mil-Standard  Needed 

It  will  not  be  sufficient  to  simply  insert  a  new  CDRL  item  in  future  contracts  to 
require  delivery  of  models.  A  standard  is  necessary  to  specify  the  format  of  the 
data,  and  the  form  and  content  of  supporting  documentation.  A  c.scussion  of  this 
requirement  is  presented  in  Section  5  of  this  report,  ai.d  a  draft  Mil-Standard  appears 
in  Appendix  B. 

1.4.4  Documentation  is  Crucial 

The  importance  of  documentation  supporting  finite  element  models  is  difficult  to 
overstate,  no  matter  where  the  models  come  from.  Undocumented  raw  data  can  be 
very  difficult  (even  dangerous)  to  use.  Documentation  is  especially  important  when 
several  variations  of  a  basic  model  exist,  as  shown  in  the  case  study  described  in 
Section  3.  Another  case  study,  showing  well-documented  models,  appears  in  Section 
4. 

1.5  Accomplishments  of  Phase  II 

A  finite  element  database  software  package  called  FEM-X  has  been  developed.  The 
software  runs  on  Unix  workstations  under  the  X  Window  System,  and  uses  the 
CADDB  engineering  database  software  that  was  developed  for  ASTROS.  Although 
FEM-X  was  developed  on  a  Sun-4  workstation  running  the  MIT  distribution  of  the  X 
Window  System  (XI 1,  Release  4),  it  was  designed  for  porting  to  other  Unix  systems 
that  support  the  X  Window  System.  The  development  of  FEM-X  is  discussed  in  Sec¬ 
tion  6  of  this  report,  and  detailed  user  information  may  be  found  in  an  accompanying 
volume,  FEM-X  User’s  Guide. 

A  draft  Mil-Standard  has  been  prepared  and  is  presented  in  Appendix  B  of  this 
report.  It  is  anticipated  that  a  version  of  this  document  will  be  adopted  so  that  the 
Air  Force  can  get  full  value  for  the  effort  exnended  by  contractors  in  developing  and 
using  finite  element  models  of  the  aircraft  that  they  produce. 

A  Plan  of  Operation  for  the  proposed  Air  Force  Finite  Element  Model  Center 
appears  in  Section  7.  The  plan  explains  in  detail  how  the  Center  will  acquire,  validate, 
document,  and  distribute  finite  element  models  to  Air  Force  users  and  contractors. 
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2.  Statement  of  the  Problem 


With  each  new  Air  Force  aircraft  system  that  has  been  developed,  finite  element 
analysis  (FEA)  has  played  a  greamr  role  in  the  stmctural  design  analysis  process. 
Older  aircraft  such  as  the  B-52  that  were  designed  entirely  by  hand  have  also  been  the 
subject  of  finite  element  analysis  in  recent  years.  Ceitainly  FEA  is  now  irreplaceable 
in  aircraft  structu’  .1  lesign  and  analysis.  However,  as  Drs.  Venkayya  and  Olsen  point 
out  in  their  paper  [1  j ,  ine  Air  Force  is  not  getting  full  value  for  the  resources  that  are 
spent  either  directly  or  by  contractors  on  FEA. 

Before  defining  tl  '  >roblem  in  more  detail,  it  will  be  useful  to  review  the  evolution 
of  finite  element  anal)  ..  and  to  summarize  the  current  state  of  affairs  in  this  field. 

2.1  Evolution  of  Finite  Element  Analysis 

The  finitQ  element  method  evolved  in  parallel  with  the  rise  of  digital  computers.  Be¬ 
cause  of  intensive  matrix  computations,  a  computer  is  necessary  for  even  the  simplest 
models.  Twenty  years  ago,  FEA  was  much  different  than  it  is  today.  NASTRAN 
had  not  yet  appeared,  and  most  organizations  supported  their  own  in-house  codes. 
Card  decks  were  standard,  and  a  big  model  had  a  thousand  degrees  of  freedom.  Pen 
plotters  were  the  state  of  the  art  in  graphics. 

At  first,  attention  was  naturally  focused  on  basic  methods:  issues  like  element 
formulations  and  equation  solution  methods.  Later,  software  reliability  and  expanded 
problem  sizes  were  addressed.  In  recent  years,  considerable  effort  has  been  expended 
on  graphical  pre-  and  post-processors.  Perhaps  the  present  effort  will  turn  out  to  be 
part  of  another  shift  in  focus  in  the  industry,  this  time  toward  protecting  investments 
in  models  by  organized  efforts  to  verify,  document,  preserve,  and  disseminate  these 
me  dels. 


2.2  Costs  of  Finite  Element  Analysis 

The  costs  of  developing  a  finite  element  model  can  be  staggering.  One  of  the  engineers 
whom  we  contacted  in  our  survey  (Section  A.l  of  Appendix  A)  quoted  a  cost  of 
$500,000  for  development  of  a  model  they  wanted.  While  this  was  an  off-the-cuff 
lemark,  it  probably  reflects  the  order  of  magnitude  of  the  costs  that  can  be  incurred 
in  modeling. 

There  are  three  major  components  of  the  overall  cost:  (1)  computer  hardware,  (2) 
computer  software,  and  (3)  engineering  manpower. 

It  is  common  knowledge  that  the  hardware  cost  of  performing  a  unit  of  com¬ 
putation  has  dropped  spectacularly  in  recent  years.  But  demand  has  kept  pace 
with  the  falling  unit  costs  so  that  hardware  expenditures  have  fallen  only  slightly  in 
absolute  terms,  perhaps  more  in  percentage  terms.  However,  these  costs  can  still  be 
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substantial.  In  large  organizations,  finite  element  analysis  tasks  can  consume  much 
of  the  power  of  a  multi-million  dollar  supercomputer. 

Engineering  software  effectiveness  has  increased  more  slowly,  but  again  demand 
has  more  than  offset  gains  here. 

Engineering  manpower  productivity  has  increased  most  slowly.  Most  of  the  man¬ 
power  productivity  gains  have  come  about  with  the  introduction  of  graphics  pre-  and 
post-processing  software.  In  both  absolute  and  percentage  terms,  manpower  costs  in 
FEA  have  risen  substantially. 

Thus  manpower  is  certainly  the  most  important  consideration  in  FEA  costs.  Two 
keys  to  controlling  manpower  costs  are  (1)  to  be  sure  that  expensive  engineers  are 
working  on  the  right  problem,  and  (2)  that  they  are  not  duplicating  someone  else’s 
work.  This  is  where  dissemination  and  documentation  play  a  key  role.  Clearly, 
if  an  Air  Force  organization  can  acquire  the  right  model  rather  than  reinvent  it, 
considerable  time  and  funds  will  be  saved.  If  the  model  is  properly  documented, 
engineers  will  be  sure  of  what  they  are  working  on. 


2.3  Air  Force  Needs  for  Finite  Element  Models 

All  developers  of  Air  Force  aircraft  use  finite  element  analysis  in  the  structural  design 
process.  Considerable  resources  (computer  hardware  and  software  costs;  engineering 
manpower)  are  devoted  to  the  development,  verification,  and  use  of  these  models. 
These  resources  are  all  provided,  at  least  indirectly,  by  the  government,  and  so  it  would 
seem  that  these  models  ought  to  belong  to  the  government.  However,  contractors  only 
deliver  what  their  contract  requires  them  to  deliver. 

There  are  many  reasons  why  Air  Force  organizations  such  as  ASD,  AFLC,  and 
AFWAL  might  need  such  models,  such  as 

•  Providing  support  for  repair  and  maintenance  operations, 

•  Investigating  new  versions  of  aircraft  (e.g.,  F15A  -  F15E), 

•  Investigating  modifications  to  existing  aircraft  (new  weapons  systems,  perfor¬ 
mance  enhancements,  etc.), 

•  Validation  of  contractors’  analyses,  and 

•  Provision  of  realistic  test  problems  for  validation  of  new  technology.  New  capa¬ 
bilities  added  to  the  ASTROS  [2]  softv'are,  for  example,  need  to  be  evaluated 
on  realistic  problems.  Models  of  existing  systems  are  ideal  for  this  purpose. 

Since  there  has  been  no  requirement  for  delivery  of  models  in  past  system  devel¬ 
opments,  models  have  been  obtained  under  less  than  satisfactory  conditions,  if  at 
all: 


•  Models  have  been  acquired  from  the  developers  through  informal  requests,  usu¬ 
ally  with  little  or  no  supporting  documentation, 

•  Models  are  sometimes  purchased  (twice,  in  effect)  from  the  original  system 
developers, 

•  Contracts  are  sometimes  let  to  third  parties  to  create  new  models. 

The  Air  Force  does  not  have  the  manpower  to  devote  to  creating  complex  models,  so 
until  now,  these  three  approaches  have  been  the  only  means  of  obtaining  the  required 
models. 

Getting  contractors  to  deliver  models  means  more  than  just  another  item  added 
to  a  CDRL.  It  will  be  necessary  to  provide  specific  requirements  regarding  documen¬ 
tation,  verification,  and  data  formats.  This  subject  is  addressed  in  some  detail  in 
Section  5.  This  specification  expands  on  the  ideas  presented  by  Dr.  Venkayya  in  his 
DID  [4]  and  in  his  conference  paper  [1]. 

2.4  Need  for  Documentation 

The  authors  know  from  personal  experience  the  importance  of  documentation  of  finite 
element  models.  This  becomes  dramatically  apparent  to  an  analyst  who  is  given  an 
undocumented  model  and  asked  to  make  modifications.  In  the  worst  case,  without 
even  any  comments  in  the  bulk  data,  the  analyst  must  begin  a  laborious  process 
of  plotting  and  running  the  model.  Plots  are  necessary  to  find  out  node  point  and 
element  locations,  and  to  relate  element  properties  and  material  types  to  specific 
areas  of  the  structure.  Test  runs  must  be  made  to  validate  the  model  for  statics  and 
dynamics. 

Documentation  issues  are  addressed  in  Section  5,  which  outlines  requirements  for 
delivery  and  documentation  of  models,  and  in  Section  6  which  documents  the  FEM-X 
database  software  that  would  not  only  preserve  existing  documentation  and  make  it 
accessible,  but  also  encourage  users  to  provide  additional  documentation. 
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3.  F-16  Case  Study:  Consequences  of  Poor 

Documentation 

Some  of  the  difficulties  and  frustrations  experienced  in  working  with  a  model  obtained 
with  little  or  no  documentation  can  be  illustrated  with  the  following  case  study  which 
was  performed  for  FDL. 


3.1  Evaluating  the  Finite  Element  Models 

A  finite  element  analysis  was  requested  to  quantify  and  evaluate  the  effects  of  real 
damage  caused  by  live  firings  on  an  F-16  wing.  Two  finite  element  models  were 
located  and  obtained.  One  model  was  an  MSC/NASTRAN  model  freshly  obtained 
from  General  Dynamics.  This  model  was  very  extensive,  containing  over  7,000  grid 
points  and  an  immense  amount  of  structural  detail.  The  other  model  had  been  around 
the  Flight  Dynamics  Laboratory  for  several  years,  so  long  that  its  origin  had  been 
forgotten.  This  model  contained  around  400  grid  points  and  over  1,000  elements. 
Plots  of  the  two  models  may  be  seen  in  Figures  1  and  2.  Note  that  the  coarse  model 
shown  includes  some  elements  within  the  fuselage,  presumably  for  modeling  the  wing 
root  stiffness. 

Neither  model  had  any  documentation,  so  it  was  necessary  to  run  the  models, 
obtain  plots,  and  study  the  results  in  order  to  gain  an  understanding  of  each  model, 
its  structure,  constraints,  and  materials.  The  larger  model  had  to  be  converted  to 
COSMIC  NASTRAN,  and  then  debugged  before  it  could  be  run.  All  this  prelimi¬ 
nary  work  used  up  considerable  engineering  manpower  and  computer  time  without 
producing  any  directly  applicable  results. 

It  would  have  been  desirable  to  use  the  more  detailed  model,  but  the  required  time 
and  manpower  would  have  been  excessive.  This  was  partly  because  so  much  of  the 
budget  was  consumed  in  preliminary  activities.  It  therefore  seemed  necessary  to  use 
the  coarse  model.  From  the  preliminary  work,  the  coarse  model  appeared  acceptable, 
since  it  seemed  to  represent  a  fully  configured  wing.  But  before  it  could  be  used  with 
confidence,  it  had  to  be  validated  in  some  way. 

3.2  Verifying  the  Coarse  Model 

When  the  same  static  load  was  applied  to  each  model,  the  predicted  deflections  were 
very  similar.  This  gave  evidence  that  the  two  models  had  essentially  the  same  bending 
stiffness.  However,  when  computed  deflections  were  compared  to  measured  deflections 
obtained  from  a  test  having  ostensibly  the  same  loads,  the  results  disagreed  by  over 
100  percent.  This  was  found  to  be  due  to  flexibility  in  the  test  fixture  jig  at  the 
wing  root.  It  should  have  been  possible  to  introduce  flexibility  into  the  root  area 
of  the  wing  model  so  that  predicted  deflections  could  be  made  to  match  the  test 
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Figure  1:  F16  Coarse  Model 


Figure  2:  F16  Fine  Model 
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results.  Again,  time  and  manpower  constraints  did  not  allow  this.  It  appeared  that 
a  comparison  of  dynamic  results  would  be  easier,  and  this  was  undertaken  instead. 

First,  the  fully  configured  FDL  finite  element  model  was  compared  to  the  results 
of  an  FDL  ground  vibration  test  on  a  similarly  configured  wing  on  an  actual  aircraft. 
The  first  two  natural  modes  matched  quite  well. 

The  next  step  was  to  compare  the  model  to  vibration  tests  of  the  test  wing,  since 
these  tests  would  be  conducted  several  times  between  firings  in  order  to  evaluate 
changes  in  the  dynamics  of  the  wing.  Since  the  test  wing  was  stripped  of  all  external 
structure,  it  was  necessary  to  remove  all  items  such  as  the  front  and  rear  flaps, 
missiles,  and  pylons  from  the  model.  This  was  a  time-consuming  task  due  to  the  lack 
of  documentation.  The  predicted  weight  was  still  about  200  pounds  greater  than  the 
measured  weight,  so  it  was  necessary  to  remove  a  percentage  of  the  nonstructural 
mass  included  in  the  model.  After  the  weight  had  been  adjusted  to  within  a  few 
pounds,  the  first  four  natural  modes  predicted  by  the  model  matched  the  vibration 
tests  within  a  few  percent. 

This  correlation  was  considered  close  enough  to  proceed  with  the  damage  study. 
Each  damage  case  was  modeled  and  static  and  dynamic  characteristics  were  tabu¬ 
lated  before  and  after  each  shot  in  order  to  assess  residual  strength  degradation  from 
damage.  Ten  damage  cases  were  analyzed  for  the  study.  Since  the  test  wing  was 
repaired  after  each  test,  these  repairs  also  had  to  be  modeled. 


3.3  Cataloging  the  Models 

Ten  damage  cases  with  two  models  each  resulted  in  twenty  configurations,  along  with 
four  configurations  of  the  undamaged  model.  (Three  test  wings  were  used  for  the 
tests,  each  varying  slightly  in  configuration  and  weight,  depending  on  the  structure 
removed.)  A  dynamic  and  a  static  analysis  was  made  with  each  model.  As  a  result, 
there  were  48  NASTRAN  decks  in  use.  The  differences  between  decks  varied  from  a 
few  dozen  cards  to  a  few  hundred.  Bookkeeping  became  very  important  in  keeping 
track  of  each  model  and  in  preventing  errors  from  propagating. 

For  similar  analyses  done  in  the  early  1970’s,  the  CDC  UPDATE  utility  was  used. 
The  original  model  was  kept  on  permanent  file,  and  a  separate  update  deck  in  punched 
card  format  was  kept  for  each  case.  These  decks  could  be  marked  and  written  on  in 
order  to  keep  them  straight. 

For  the  F-16  study,  complete  decks  were  kept  on  permanent  files.  The  CDC 
permanent  file  system  allows  only  seven  characters  for  file  names,  so  a  shorthand 
system  had  to  be  devised  and  a  manual  log  book  kept.  After  models  were  no  longer 
actively  needed  they  were  archived  to  the  Central  File  System  (CFS).  The  CFS  allows 
file  names  up  to  about  30  characters  long  so  that  descriptive  titles  could  be  used.  The 
approach  used  here  was  superior  to  the  old  UPDATE  method  because  the  engineer 
could  use  a  screen  editor  instead  of  the  cumbersome  line-oriented  directives  required 
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by  UPDATE.  However,  one  advantage  of  UPDATE  was  lost.  When  one  model  is 
derived  from  anotner,  the  UPDATE  method  provides  an  explicit  indication  (in  the 
form  of  correction  sets)  of  the  differences  between  the  two  models.  No  such  direct 
comparison  is  possible  when  separate  files  are  kept  for  all  models. 

Comment  cards  were  inserted  in  the  various  decks  to  describe  the  changes  that 
were  made. 

3.4  How  a  Database  might  have  Helped 

If  FEM-X  had  been  available  when  this  study  was  done,  it  could  have  helped  in 
three  ways,  it  could  have  provided  a  better  starting  point  for  the  effort,  smoother 
procedures  during  the  effort,  and  an  end  product  that  would  be  more  accessible  to 
future  users. 

If  a  well-documented  and  verified  model  had  existed  prior  to  this  effort,  a  savings  of 
at  least  25%  of  the  labor  would  have  been  possible,  according  to  the  engineer  who  did 
the  work.  The  work  would  have  been  easier  because  it  would  not  have  been  necessary 
to  track  models  and  file  names  manually.  FEM-X  would  have  provided  automated 
tracking  of  models,  with  tracing  of  the  derivation  of  one  model  from  another.  It 
would  have  provided  both  the  convenience  of  a  screen  editor  and  the  traceability 
of  UPDATE.  It  would  have  encouraged  him  to  provide  adequate  documentation  at 
every  step,  while  providing  reversibility  of  all  changes.  Finally,  although  the  CFS 
works  well  when  it  is  up,  it  goes  down  frequently  (or  did  when  the  study  was  done). 
This  aggravation  would  have  been  avoided  with  a  database  implemented  on  a  VAX. 
In  summary,  while  the  job  got  done,  the  engineer  likened  it  to  using  a  hand  saw  in 
comparison  to  a  power  saw. 

The  same  engineer  has  stated  that  he  would  be  able  to  find  the  files  and  notes 
and  continue  the  study  with  relatively  little  difficulty  if  he  were  called  on  to  do  so. 
He  also  stated  that  it  would  be  virtually  impossible  for  anyone  else  to  do  so  without 
his  assistance. 
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4.  B-l  and  F-15E  Case  Studies:  Well-Documented 
Models 

In  this  section,  two  large  finite  element  aircraft  analysis  programs  are  reviewed.  They 
were  selected  because  they  provide  examples  of  well-documented  models. 


4.1  B-l  Model  for  an  Airloads  Research  Study 

Rockwell  International  developed  a  model  of  the  B-l  aircraft  number  two  (A/C-2) 
for  NASA/Dryden  Research  Facility  in  the  early  1980’s  [5].  The  purpose  of  the  study 
was  to  utilize  flight  data  acquired  during  B-l  flights  and  perform  analyses  of  these 
data  beyond  the  scope  of  Air  Force  requirements.  Specifically,  the  structural  model 
was  to  be  used  to  calculate  influence  coefficients  which  would  then  be  passed  to  the 
NASA  aerodynamics  code,  FLEXSTAB.  Although  detailed  models  were  available  at 
Rockwell,  it  was  decided  to  develop  coarse  models  so  that  the  aerodynamic  studies 
could  be  executed  efficiently.  Seven  substructures  were  modeled  (wing,  forward  fuse¬ 
lage,  aft  fuselage,  horizontal  and  vertical  stabilizers,  fairings,  and  nacelle)  with  a  total 
of  about  3520  grid  points.  The  report  appeared  in  five  volumes  (NASTRAN  model 
plans;  horizontal  stabilizer,  vertical  stabilizer,  and  nacelle  structures;  wing  structure; 
fuselage  structure;  and  fairing  structure). 

This  report  is  cited  because  it  represents  a  thoroughly  documented  finite  element 
model.  The  introduction  begins  by  explaining  the  reason  for  the  model,  i.e.,  providing 
flexibility  matrices  of  sufficient  complexity  for  use  with  FLEXSTAB,  an  aeroelastic 
code.  This  is  followed  by  brief  physical  descriptions  of  the  aircraft  as  a  whole,  and 
each  component. 

There  is  an  explanation  of  the  DMAP  code  that  was  written  to  provide  the  re¬ 
quired  matrices  for  interfacing  with  FLEXSTAB.  Following  this  is  a  package  of  engi¬ 
neering  drawings  that  were  used  in  developing  the  model. 

Separate  volumes  are  provided  for  each  substructure.  The  wing  volume,  volume 
III,  for  example,  begins  with  some  engineering  drawings  and  then  gives  an  explana¬ 
tion  of  NASTRAN  input,  consisting  of  several  pages  copied  from  the  User’s  Manual. 
This  would  probably  be  unnecessary  today  with  NASTRAN  having  become  so  well 
known.  There  is  a  page  that  explains  the  numbering  scheme  that  was  used  (e.g., 
grid  number  XXYY  lies  on  rib  XX  and  spar  YY).  Similar  conventions  are  given  for 
element  numbers. 

Following  this  is  an  exhaustive  series  of  plots  generated  by  NASTRAN.  It 
appears  that  every  grid  point  and  every  element  is  labelled  in  at  least  one  plot. 
For  example,  see  Figures  3  through  6  which  show  all  grid  and  element  numbers  for 
the  outboard  wing  lug  area. 

The  text  asserts  that  the  model  was  checked  for  continuity,  constraints,  etc.,  using 
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NASTRAN  wing  model 
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Figure  5:  Lower  Outboard  Wing  Pivot  Lug  Grid  Points 
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an  interactive  graphics  code.  Results  are  presented  for  unit  loading  at  each  of  a 
number  of  selected  influence  coefficient  points.  Plots  show  selected  displacements 
plotted  versus  results  predicted  by  the  detailed  B-l  model.  Good  agreement  is  shown. 

Finally,  a  sorted  bulk  data  echo  of  over  4000  cards  is  given. 

Thus,  the  report  presents  practically  all  the  information  that  would  be  needed 
by  an  analyst  assigned  to  pick  up  this  model  and  use  it.  Engineering  drawings  are 
given,  complete  plots  are  presented,  the  numbering  scheme  is  explained,  and  evidence 
of  verification  is  given.  The  only  category  not  covered  is  documentation  of  loads. 
There  were  no  loads  per  se,  since  the  purpose  of  the  study  was  to  develop  influence 
coefficients. 

As  an  aside,  one  wonders  whether  the  project  would  be  undertaken  at  all  if  it  were 
proposed  today.  If  the  detailed  model  referenced  in  the  report  were  available  from 
Rockwell,  and  given  today’s  tradeoff  between  engineering  labor  costs  and  computer 
costs,  it  might  be  better  to  simply  run  with  the  complex  model.  Second,  one  wonders 
whether  any  contractor  other  than  Rockwell  could  have  done  the  job.  Thi°  would 
depend  on  whether  the  detailed  model  (which  was  of  course  created  bj  r  ..ckwell) 
could  have  been  obtained  by  another  contractor,  and  if  so,  whether  it  would  have 
been  documented  adequately. 

4.2  F-15E  Model 

Another  contractor  report  is  cited  as  an  example  of  good  documentation  of  loading 
conditions.  This  is  the  stress  report  for  the  F15-E  aircraft,  [6],  specifically,  section 
11.9.2,  Loading  Conditions. 

The  section  on  loading  conditions  begins  with  a  discussion  of  factors  of  safety, 
ultimate  loads,  thermal  effects,  and  conservative  combinations  of  engine  thrust  loads, 
flight  loads,  and  cockpit  pressures.  Crash  loads  and  pilot  applied  loads  are  also 
considered.  The  computer  program  used  to  develop  load  distributions  is  referenced. 

Table  1  (copied  from  table  1 1.9.2- 1  of  the  report)  shows  a  listing  of  load  conditions 
that  were  selected  as  critical  for  the  forward  fuselage.  Each  line  of  the  table  indicates 
the  condition  number  used  in  NASTRAN,  the  engine  otirust  (max  or  min),  Mach 
number,  altitude,  a  brief  description  of  the  condition,  limit  load  factors,  cockpit 
pressure,  a  description  in  terms  of  the  the  effects  on  the  structure,  and  an  indication 
of  the  areas  that  are  critical  for  the  particular  condition.  This  last  item  would  be 
especially  useful  for  someone  picking  up  the  model  for  the  first  time,  intending  to  use 
it  in  an  optimization  study,  for  example. 


17 


18 


1 


ii 

4J  4/1 


•j 


9 


• 

• 

• 

m 

• 

• 

— 

— 

• 

MB 

• 

• 

• 

• 

• 

• 

C 

c 

c 

c 

c 

c 

o 

o 

o 

o 

o 

o 

a. 

a. 

A 

a. 

a. 

0. 

CD 

o 

o 

* 

o 

w 

O 

• 

w 

O 

w 

•  p 

. 

k. 

o 

c 

w 

w 

0 

o 

o 

c 

JZ 

c 

c. 

c 

X 

c 

X 

c 

X 

C  X 

c 

X 

o 

o 

o 

w 

40 

o 

V 

40 

o 

k. 

40 

0 

w 

40 

o 

w 

40 

O  (0 

k. 

o 

w 

(0 

CL 

L» 

9 

o 

9 

9 

O 

• 

9 

a 

• 

9 

O 

• 

9 

P 

•  — 

9  O 

• 

9 

o 

•  ■ 

40 

a 

m0 

C 

** 

c 

■MM 

C 

MB 

C  mb 

C 

■?  s 

c 

O 

c 

O 

c 

0 

c 

O 

c 

o  c 

o 

c 

o 

o 

o 

-J 

o 

mJ 

o 

-4  o 

-J 

o 

X  c 

• 

• 

• 

• 

• 

M 

9 

M 

N 

•  — 

• 

N 

a  o 

O 

o 

p 

v! 

o 

X 

c 

o 

a. 

P 

40 

o 

X 

p 

Jo 

o 

X 

p 

40 

w 

O 

X 

P 

A 

w 

O 

X 

p  k. 

to  5 

P 

40 

w 

1 

c  a 

2  1 

•* 

u 

< 

F.S 

< 

3 

3 

3 

3 

■ 

• 

• 

• 

• 

• 

■ 

• 

• 

m 

m 

• 

9 

• 

9 

9 

• 

9 

9 

9 

9 

9 

C 

C 

k. 

C 

C 

w 

C 

c 

• 

Ol 

— 

9 

— 

• 

Ob 

MB 

• 

• 

A 

• 

9 

a 

3 

P 

3 

P 

3 

P 

3 

P 

3 

P 

3 

P 

3 

9 

c 

cr 

C 

9 

c 

9 

C 

9 

Mb' 

C 

9 

C 

9 

p  p 

• 

• 

h. 

— 

• 

k. 

• 

k. 

•M 

• 

k. 

k. 

___ 

03 

O 

a. 

CD 

o 

03 

O 

a. 

CD 

O 

A 

O 

a 

A 

O 

A 

O 

CL 

P  6 

h- 

►- 

X 

-* 

X 

X 

.* 

X 

X 

u 

P 

P 

o 

P 

P 

u 

P 

P 

a 

C 

o 

c 

c 

u 

C 

a 

• 

C 

41 

o 

o 

• 

C 

41 

• 

C 

41 

o 

o 

S  : 

M* 

X 

O 

X 

X 

o 

X 

P 

X 

X 

w 

p 

X 

k. 

P 

X 

X 

i. 

P 

X 

w 

P 

X 

m  > 

—  o 

A 

s 

X 

s 

• 

X 

% 

• 

X 

! 

• 

X 

% 

• 

X 

s 

• 

X 

s 

• 

X 

X  « 

O 

o 

40 

ft 

u 

40 

u 

40 

ft 

C 

40 

o 

40 

> 

o 

40 

u 

40 

II 

a  cc 

z 

— • 

BMB 

• 

• 

• 

• 

a 

a 

a. 

A 

o 

• 

o 

• 

A 

• 

A 

A 

a. 

A 

a 

A 

A 

A 

A 

A 

A 

A 

A 

A 

A 

■A 

X 

♦ 

X 

X 

X 

* 

X 

* 

X  X 

A  • 

47 

X 

X 

X 

X 

X 

* 

X 

•  X 

* 

X 

r 

X 

r 

X 

f 

X 

1* 

X 

1 

1 

1  1 

1 

1 

i 

1 

i 

1 

1 

1 

1 

1 

* 

M 

X  N 

X 

N 

X 

H 

X 

N 

X 

N 

X 

N 

z 

Z 

N 

N 

Z 

Z 

Z 

Z 

z 

z 

Z 

z 

z 

z 

9 

9 

9 

9 

9 

9 

9 

c 

C 

C 

C 

C 

C 

c 

““ 

— 

SM 

BM 

m# 

■“  MB* 

— 

MB 

M» 

_ 

MB 

3 

—  3 

MB 

3 

3 

3 

MB 

3 

3 

O 

tar 

O 

O  O 

o 

o 

O 

o 

o 

o 

0 

o 

o 

o 

* 

A 

A 

A 

A 

A 

A 

“* 

•M 

M 

_ 

§ 

3 

§ 

3 

3 

3 

3 

3 

a 

A 

A 

A 

A 

A 

A 

A 

A 

A 

-J 

J 

J 

J 

J 

J 

10 

40 

40 

40 

40 

40 

A 

01 

A 

A 

A 

A 

m 

A 

9 

9 

9 

A 

9 

A 

A 

A 

A 

A 

A 

A 

A 

» 

P 

C 

C 

M 

n 

C 

c 

i 

5 

i 

1 

9 

a 

5 

a 

- 

X 

*0 

«r 

A 

A 

X 

7 

T* 

MB 

1 

I 

| 

T 

1 

n 

A 

A 

A 

A 

X 

A 

9 

A 

A 

A 

A 

A 

c 

o 

x  m 

a  — 
o  «** 
c  — 
o  • 
o  -> 


o 

o  c 
W  o 


a  o 

3 

o  - 

-J  u 

z  < 


a» 

T 


19 


Table  1.  Forward  fuselage  design  loading  conditions  (Continued) 
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Table  1.  Forward  fuselage  design  loading  conditions  (Continued) 


5.  Standards  for  Delivery  of  Finite  Element 
Models 

The  reasons  why  the  Air  Force  should  require  its  contractors  to  deliver  finite  element 
models  developed  in  the  course  of  their  work  have  already  been  noted.  In  order  to 
implement  this  requirement  for  the  delivery  of  future  systems,  a  Mil-Standard  must 
be  developed.  This  section  presents  some  information  on  finite  element  models,  pre¬ 
processors,  and  NASTRAN  as  a  standard.  This  background  information  leads  into 
a  preliminary  outline  of  a  Mil-Standard  directed  toward  delivery  of  finite  element 
models. 


5.1  Background  on  Finite  Element  Models  and  Their  Use 

This  section  begins  with  a  general  discussion  of  finite  element  modeling  as  background 
for  the  subsequent  discussion  of  delivery  requirements  for  finite  element  models.  More 
information  on  finite  element  analysis  may  be  obtained  from  a  standard  finite  element 
text  such  as  [7]  or  from  the  handbook  series  published  by  MacNeal-Schwendler  [8]  [9] 
[10]  [11]  [12]. 

In  finite  element  structural  analysis,  we  are  solving  some  kind  of  matrix  equation 
which  can  be  stated  in  a  general  way  as 

/(K(U,tf,w),M,B,U(t),U(0,U(0,«)  =P(K,M,Ult,0,u/)  (1) 

Here  the  stiffness,  mass,  and  damping  matrices  are  denoted  by  K,  M,  and  B;  dis¬ 
placements  by  U,  loads  by  P,  time  by  t,  frequency  by  u,  and  temperature  by  9, 
showing  that  stiffness  may  be  a  function  of  displacement,  temperature,  or  frequency, 
and  that  loads  may  be  functions  of  stiffness,  mass,  displacement,  time,  frequency,  or 
temperature.  Thus,  the  familiar  linear  static  analysis  would  be  just 

KU  =  P  (2) 

whereas  a  geometrically  nonlinear  transient  analysis  with  follower  forces  would  be 
written 

K(U)U  +  BU  +  MU  =  P(t,U)  (3) 

This  example  shows  that  nonlinearity  is  usually  introduced  implicitly  (i.e.,  K  and 
P  are  shown  as  functions  of  the  independent  variable  U).  This  leads  to  iterative 
solutions  of  the  equations. 

Based  on  this  general  formulation,  we  may  state  three  basic  questions  facing  the 
modeler: 

1.  What  equations  are  to  be  solved;  i.e.,  what  is  /?  Is  this  a  static  or  dynamic 
problem,  steady-state  or  transient,  linear  or  nonlinear? 
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2.  How  to  develop  K,  M,  and  B.  This  is  determined  by  the  layout  of  grids  and 
elements,  and  by  element  types.  These  questions  in  turn  are  governed  primarily 
by  the  objective  of  the  analysis.  Geometric  symmetry  may  be  used  to  advantage 
in  laying  out  the  model. 

3.  How  to  represent  the  load  P.  Is  it  static,  transient,  or  steady-state?  Does  it 
vary  with  temperature,  displacement,  etc.? 

Engineering  expertise  is  needed  to  answer  these  questions,  based  on  the  nature  of 
the  structure,  the  excitations,  and  the  physical  phenomenon  being  modeled.  Each  of 
these  questions  is  now  discussed  in  turn. 

5.1.1  Six  Kinds  of  Finite  Element  Models 

The  kind  of  mesh  that  is  chosen  (coaise  or  fine)  and  the  types  of  elements  are  de¬ 
termined  primarily  by  the  objective  of  the  analysis.  We  may  identify  five  kinds  of 
NASTRAN  finite  element  models  which  are  distinguished  mainly  by  the  kind  of  ele¬ 
ments  that  are  used  and  the  density  of  the  mesh.  The  classifications  are  rather  broad 
and  overlap  substantially,  as  will  be  seen.  For  aircraft  structures,  only  three  kinds 
are  typically  used: 

1.  Static  models 

2.  Dynamic  models 

3.  Aeroelastic  models 

Two  other  kinds  are  less  common  in  aircraft  modeling: 

4.  Heat  transfer  models 

5.  Acoustic  cavity  models 
and  one  is  not  used  at  all: 

6.  Electromagnetic  models 

Static  models  are  designed  to  provide  stress  and  deflection  predictions.  A  high 
degree  of  mesh  refinement  is  generally  required  for  stress  analysis  for  two  basic  rea¬ 
sons:  (1)  high  stress  gradients  are  commonly  observed,  and  (2)  when  displacements 
are  the  independent  variables,  as  is  the  case  in  all  modern  finite  element  codes,  stresses 
are  computed  by  differentiating  the  approximate  displacements,  thus  introducing  ad¬ 
ditional  error  which  must  be  compensated  for  by  increased  refinement. 

Dynamic  models  are  generally  used  to  compute  natural  frequencies  and  mode 
shapes.  They  may  also  be  used  to  compute  transient  or  steady-state  displacements 


and  accelerations.  Such  analyses  require  considerably  less  detail  than  static  models 
since  mode  shapes  are  usually  distributed  widely  over  the  structure  and  are  thus 
insensitive  to  local  variations.  Two  exceptions  may  be  noted:  first,  when  gravity 
loads  are  included,  there  must  be  sufficient  accuracy  in  the  mass  distribution  to 
produce  accurate  loads.  Second,  dynamic  stresses  may  also  be  of  interest.  In  this 
case  more  detail  must  be  introduced,  at  least  locally.  Also,  if  a  dynamic  analysis  is 
desired  but  only  a  static  model  is  available,  it  may  be  more  economical  to  pay  for  the 
additional  computer  time  required  to  carry  out  dynamic  analysis  with  a  static  model 
than  to  expend  the  manual  or  semi-automated  effort  required  to  simplify  the  static 
model. 

Aeroelastic  models  involve  a  mathematical  model  of  the  aerodynamics  as  well 
as  a  structural  model.  Aerodynamic  models  may  be  used  to  predict  static  aeroelas¬ 
tic  stability  using  a  real  eigenvalue  solution,  and  for  dynamic  aeroelastic  stability. 
Aerodynamic  models  must  be  coupled  with  structural  models  in  order  to  predict 
aeroelastic  effects.  Since  the  meshes  for  the  two  models  do  not  coincide,  interpolation 
must  be  used.  Interpolation  is  not  a  trivial  matter,  but  several  methods  are  available. 

Heat  transfer  models  are  generally  similar  to  static  models  with  regard  to  the 
geometry  of  elements.  Heat  transfer  analysis  capabilities  are  included  in  NASTRAN 
as  a  sort  of  byproduct  of  the  structural  analysis  capability.  The  same  elements  are 
used,  but  NASTRAN  generates  heat  capacitance  and  conductance  matrices  instead 
of  stiffness  and  mass  matrices,  temperatures  in  place  of  displacements  (thus  only  one 
degree  of  freedom  per  node),  and  heat  sources  and  sinks  in  place  of  loads.  Prediction 
of  accurate  internal  heat  flux  distributions  is  similar  to  prediction  of  accurate  stresses 
in  that  generally  fine  meshes  are  required. 

Acoustic  cavity  models  appeared  in  NASTRAN  as  something  of  an  adjunct 
capability  which  is  not  particularly  relevant  to  aircraft  analysis,  but  is  mentioned  here 
only  for  completeness.  The  method  is  intended  for  analysis  of  structure-acoustics 
interaction  in  rocket  motors  with  axisymmetric  geometry. 

Electromagnetic  models  are  used  to  determine  the  magnetic  fields  in  and  about 
ferromagnetic  bodies.  A  finite  element  approximation  to  Maxwell’s  equations  is  de¬ 
veloped  and  solved. 

5.1.2  Symmetry 

Most  finite  element  models  are  general  three-dimensional  models.  Others  exhibit 
special  symmetries  which  can  be  exploited  by  NASTRAN.  Reflective  symmetry  is 
handled  by  simple  constraints  applied  at  points  on  symmetry  planes.  Cyclic  sym¬ 
metry  is  handled  by  special  solution  methods  in  NASTRAN.  This  category  cov¬ 
ers  situations  having  rotational  symmetry;  that  is,  the  structure  looks  the  same 
after  rotation  about  an  axis  through  a  given  angle  (which  must  divide  360  degrees 
evenly).  Axisymmetry  is  a  limiting  case  of  cyclic  symmetry.  It  is  still  supported 
in  NASTRAN  by  special  elements  based  on  Fourier  series  expansions  in  the  circum- 
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ferential  direction,  but  these  special  elements  may  be  considered  obsolete  since  the 
introduction  of  the  more  general  cyclic  symmetry  capability. 

It  is  not  necessary  that  loads  be  symmetric  in  order  to  exploit  geometric  symmetry. 
In  the  case  of  reflective  symmetry  about  the  plane  x  =  0,  for  example,  a  general  load 
P  is  decomposed  into  symmetric  and  anti-symmetric  components;  i.e., 

P(x,y,z)  =  Ps{x,y,z) +PA(x,y,z)  (4) 

where 

Ps(x,2/,2)  =  p  s(-x,y,z)  (5) 

PA(x,y,z)  =  -PA{-x,y,z) 

A  static  solution  may  be  obtained  by  solving 


KsUs  =  P  s 


and 


KaVa  =  PA 


and  recovering  the  total  solution 


U  =  Us  +  Va 


for  the  x  >  0  side,  or 

U  =  Vs  -  Ua 

for  the  x  <  0  side.  Even  though  two  solutions  are  required,  the  cost  is  less  than  a 
solution  of  the  full  model  because  the  matrix  decomposition  time  will  be  less  by  a 
factor  of  about  four. 

Similar  derivations  are  possible  for  solution  of  general  loads  acting  on  cyclic  sym¬ 
metric  structures  [8j. 

5.1.3  Equation  Types 

The  simplest  form  of  structural  analysis  is  static  analysis  in  which  we  solve  the  linear 
matrix  equation  shown  in  Eq.  2.  Static  analysis  is  justified  when  the  loads  change  only 
slowly.  In  most  cases,  flight  maneuver  loads,  for  example,  are  treated  as  quasi-static. 

In  linear  eigenvalue  analysis  wc  solve 


(K  -  u/2M)U  =  0  (6) 

to  obtain  natural  frequencies  fi  =  uii/(2n)  and  mode  shapes  U,.  This  kind  of  analysis 
is  very  important  because  frequencies  and  mode  shapes  tell  a  lot  about  the  dynamics 
of  a  structure. 


24 


Static  stability  analysis  is  almost  never  required  in  aircraft  analysis,  but  is  men¬ 
tioned  here  for  completeness.  The  eigenvalue  buckling  problem 


(K  +  AKd)U  =  0 


(7) 


is  formed  in  terms  of  the  “differential  stiffness”  Kd,  and  solved  for  the  lowest  root  A. 
Kd  is  the  linearized  incremental  stiffness  associated  with  a  particular  applied  load. 

Dynamic  loads  may  be  classified  as  transient  or  steady-state.  Transient  problems 
are  solved  by  forward  integration  of  the  equations  of  motion.  Steady-state  problems 
are  important  in  the  analysis  of  random  excitations.  Both  problems  are  usually 
formulated  in  terms  of  modal  superposition  in  which  multipliers  of  a  selected  set  of 
normal  modes  are  used  as  independent  degrees  of  freedom  rather  than  node  point 
displacements. 

Most  structural  analysis  is  based  on  linearized  equations  of  motion  and  linearized 
stress-strain  laws.  Nonlinearity  is  encountered  more  frequently  in  heat-transfer  anal¬ 
ysis,  as  when  temperature-dependent  thermal  properties  or  nonlinear  radiation  laws 
are  specified.  In  some  cases,  which  are  seldom  encountered  in  aircraft  analysis,  one 
or  both  of  these  assumptions  may  not  unjustified.  In  these  cases  special  iterative 
analysis  methods  must  be  employed.  Nonlinear  analysis  is  usually  difficult  and  time- 
consuming,  requiring  an  analyst  with  special  skills. 


5.1.4  Definition  of  Loads 

Definition  of  loads  for  aircraft  analysis  is  basically  a  matter  of  defining  the  flight 
conditions  to  be  used.  Loads  usually  represent  a  certain  load  factor,  altitude,  airspeed, 
gross  weight,  store  loads  and  many  other  considerations.  Ground  loads  for  taxi  or 
landing  landing  impact  may  also  have  to  be  simulated.  Obtaining  these  loads  may 
require  running  other  computer  codes  such  as  aerodynamic  or  taxi  programs.  Ideally  a 
finite  element  model  would  come  with  a  series  of  such  loads  representing  the  conditions 
which  are  critical  for  the  design  of  the  aircraft.  Unfortunately,  different  loads  are 
critical  for  different  parts  of  the  structure.  A  rolling  pullout  may  drive  the  design  of 
one  component,  while  a  different  maneuver  may  be  more  important  to  another. 

The  manufacturer’s  stress  report  generally  lists  the  criteria  used  in  the  design 
of  each  component  and  shows  how  the  stress  analysis  was  performed.  These  stress 
reports  form  a  valuable  adjunct  to  a  finite  element  model,  but  they  are  usually  pub¬ 
lished  in  limited  quantities  (only  a  few  copies  of  each  volume,  while  the  volumes  may 
run  to  a  hundred  or  more)  and  are  usually  not  available  to  most  engineers.  It  is  rec¬ 
ommended  that  the  Model  Center  have  a  copy  of  the  stress  reports  available.  Loads 
for  a  limited  number  of  well-defined  loading  conditions  should  be  part  of  the  model. 


25 


5.2  NASTRAN  as  a  Standard 


NASTRAN  was  developed  originally  for  NASA  by  contractors.  Subsequently,  com¬ 
mercial  versions  appeared,  among  which  MSC/NASTRAN  is  predominant.  While 
several  other  commercial  finite  element  codes  exist,  none  of  them  competes  seriously 
in  the  aerospace  industry.  COSMIC  NASTRAN,  the  original  NASA  version,  still 
exists  and  is  being  maintained,  modestly  enhanced,  and  marketed.  While  it  is  used 
at  a  few  government  installations,  we  know  of  no  aerospace  companies  that  use  it. 
Some  aerospace  companies  continue  to  use  in-house  finite  element  codes,  but  nearly 
all  use  NASTRAN  at  least  as  an  adjunct  to  their  in-house  code.  FDL’s  ASTROS 
program  also  uses  NASTRAN  input  format.  These  facts  make  it  reasonable  to  spec¬ 
ify  NASTRAN  format  in  the  proposed  Mil-Standard,  and  also  to  adopt  NASTRAN 
format  for  storage  of  models  in  the  Model  Center. 

The  question  remains  as  to  whether  a  particular  form  of  NASTRAN  input  should 
be  required  for  model  delivery.  The  various  versions  of  NASTRAN  have  diverged  to 
some  extent  as  new  enhancements  have  been  added.  The  divergences  have  mainly 
taken  the  form  of  new  capabilities,  each  of  which  generally  brings  with  it  a  few 
new  bulk  data  cards  or  new  fields  on  existing  cards  In  a  few  circumstances,  old 
capabilities  have  been  dropped  (e.g.,  the  QUAD2  element  has  been  dropped  from 
MSC/NASTRAN).  Also,  some  new  bulk  data  formats  have  been  added  (free  format 
options).  Perhaps  as  a  result  of  conservatism  and  inertia  in  the  engineering  com¬ 
munity,  these  changes  have  not  been  overwhelming.  Typically,  an  aircraft  structural 
model  rarely  uses  features  that  are  not  common  to  all  versions,  so  that  translation  is 
can  be  be  performed  without  ambiguity.  When  aeroelastic  features  are  used,  there  is 
some  difficulty,  but  again  typically  not  insurmountable.  It  is  expected  that  the  trans¬ 
lator  prepared  as  part  of  this  effort  (see  Section  6.2.4)  will  make  the  debate  about 
COSMIC  versus  MSC  format  immaterial.  The  translator  automates  conversion  of 
bulk  data  files  among  any  of  three  formats  (COSMIC,  MSC,  ASTROS).  It  translates 
unambiguous  entries  without  comment.  Where  there  is  some  ambiguity  or  lack  of 
overlap,  the  translator  either  makes  an  assumption  or  makes  no  translation,  flagging 
the  situation  so  the  analyst  can  make  a  judgement. 

It  light  of  the  forgoing,  it  is  recommended  that  files  prepared  for  any  publicly  or 
commercially  available  version  of  NASTRAN  be  acceptable.  At  present,  these  include 
COSMIC  NASTRAN,  MSC/NASTRAN,  UAI/NASTRAN,  and  CSA /NASTRAN. 
Although  the  latter  two  versions  are  not  currently  supported  by  the  translator,  files 
in  these  formats  could  be  dealt  with  in  either  of  two  ways:  (1)  translate  them  as 
COSMIC  files,  or  (2)  add  UAI/NASTRAN  or  CSA/NASTRAN  to  the  translator. 
The  translator  is  designed  to  facilitate  addition  of  new  codes  in  thai  no  source  code 
modification  is  necessary;  instead,  the  ASCII  template  file  which  drives  the  translator 
is  modified  by  somewhat  with  knowledge  of  NASTRAN,  without  any  modification  to 
the  translator  source  code. 
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5.3  Pre-  and  Post-Processors 


Finite  element  pre-processors  are  programs  (usually  graphics-oriented)  that  can  be 
used  to  generate  finite  element  models  in  a  semi-automated  manner.  Generally  speak¬ 
ing,  users  define  certain  key  nodes  (at  comers,  for  example)  and  then  specify  that  a 
mesh  of  interior  nodes  and  elements  is  to  be  filled  in  according  to  certain  specificar 
tions. 

Automatic  mesh  generation  is  convenient  when  applicable,  but  geometric  irreg¬ 
ularities  in  a  structure  may  limit  its  usefulness.  In  these  cases  manual  definition  of 
many  nodes  and  elements  will  still  be  necessary.  In  these  cases,  pre-processors  are 
still  valuable  for  the  ability  to  view  the  model  with  interactive  control  of  rotation, 
zoom,  hidden  surface  removal,  etc. 

Pre-processors  generally  accept  commands  either  from  the  keyboard  or  from  com¬ 
mand  files.  Since  keyboard  commands  are  not  recorded  permanently,  command  files 
are  the  best  way  to  generate  models  in  production  work.  In  these  cases  the  user  may 
not  pay  much  attention  to  the  bulk  data  file  that  is  generated  by  the  pre-processor, 
considering  the  pre-processor  command  file  to  be  the  real  source  of  the  model  and 
the  focus  of  his  effort.  In  other  cases,  however,  manual  editing  of  the  bulk  data  may 
be  necessary.  If  a  user  makes  nonrepeatable  (or  difficult-to-repeat)  changes  to  a  bulk 
data  deck,  he  has  then  invalidated  the  pre-processor  command  file,  making  it  difficult 
or  impossible  to  go  back  to  the  pre-processor  and  make  changes  at  that  level.  This 
also  leads  to  the  possibility  that  some  unsuspecting  future  user  may  assume  that  the 
command  file  is  still  current.  Thus  we  may  distinguish  three  situations  in  the  use  of 
pre-processors: 

1.  Where  little  or  no  editing  of  the  bulk  data  is  required,  the  pre-processor  com¬ 
mand  file  should  be  considered  the  source  of  the  model.  Any  editing  of  the  bulk 
data  should  be  done  in  a  repeatable  manner. 

2.  Where  extensive  editing  of  the  bulk  data  is  required,  it  may  be  best  to  “bum 
bridges,”  abandoning  the  pre-processor  once  extensive  changes  to  the  bulk  data 
have  been  made. 

3.  Borderline  cases  have  to  be  handled  with  judgement,  but  it  must  always  be 
clear  whether  the  pre-processor  command  file  is  current  or  not. 


NASTRAN  has  been  selected  as  a  standard  finite  element  code  for  this  effort. 
No  such  choice  is  possible  for  pre-processors,  however,  since  no  one  code  has  reached 
the  position  of  prominence  that  NASTRAN  has  reached  among  finite  element  codes. 
Therefore,  no  attempt  will  be  made  to  develop  standards  that  relate  to  pre-processing 
codes. 
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5.4  Validation  of  Models 

It  is  very  important  to  establish  confidence  in  a  finite  element  model,  especially  one 
obtained  from  another  organization.  Validation  of  models  is  by  no  means  an  exact 
science,  but  depends  partly  on  experience  and  judgement.  Nor  is  validation  a  simple 
yes/no  judgement.  For  example,  a  static  model  may  (deliberately)  predict  accurate 
stresses  in  one  region  and  not  another.  Dynamic  models  must  be  judged  in  terms  of 
the  highest  frequency  that  should  be  accepted.  They  may  also  be  set  up  to  suppress 
unwanted  modes  such  as  in-plane  modes. 

As  was  mentioned  in  Section  5.1,  there  are  some  mathematical  theorems  regarding 
convergence  of  finite  element  models  with  increasing  mesh  refinement.  Only  recently, 
with  the  advent  of  commercial  versions  of  the  so-called  p-version  of  finite  element 
analysis  such  as  MSC/PROBE,  have  these  theorems  begun  to  have  practical  appli¬ 
cation.  The  p-version  of  FEA  is  a  systematic  approach  to  model  refinement  wherein 
the  order  of  the  shape  functions  of  certain  elements  is  increased  in  response  to  stress 
gradient  data.  (In  the  h-version,  by  contrast,  accuracy  is  enhanced  by  adding  more 
elements  with  unchanged  shape  function  order.)  However,  in  aircraft  structures  there 
is  often  little  choice  about  where  to  locate  node  points.  Having  defined  node  points 
at  all  the  places  dictated  by  the  geometry  of  the  structure  (i.e.,  at  stiffeners,  cutouts, 
thickness  changes,  etc.),  the  analyst  often  finds  his  “budget”  of  node  points  exhausted, 
or  nearly  so. 

There  are  a  number  of  diagnostic  checks  performed  by  NASTRAN  that  should 
be  checked  as  a  first  step  in  validating  a  model.  Assuming  a  model  is  free  of  simple 
format  errors  and  typos,  the  next  validation  step  would  be  generation  of  plots.  These 
can  be  used  to  check  visually  for  elements  that  are  misshapen,  node  points  out  of 
place,  etc.  Plots  are  best  generated  with  a  pre-processing  program,  but  NASTRAN’s 
plot  capability  can  also  be  used.  Also,  the  diagnostic  program  called  RATS  can  be 
used  to  check  models  for  unacceptable  or  borderline  values  of  aspect  ratio,  interior 
angle,  and  skew.  Next,  simple  static  loads  can  be  applied.  NASTRAN  prints  several 
diagnostic  messages  that  can  help  uncover  errors  in  element  connections,  poor  con¬ 
straint  sets,  etc.  Simple  node  point  singularities  are  detected  automatically.  More 
complex  mechanisms  or  near-mechanisms  can  be  detected  by  a  matrix  conditioning 
number  (ratio  of  maximum  factor  diagonal  to  matrix  diagonal).  Acceptable  values 
for  this  nondimensional  ratio  range  from  105  to  107.  A  residual  error  ratio  which 
is  calculated  for  static  analysis  can  also  point  to  stiffness  singularities.  In  dynamic 
analysis,  spurious  strain  energy  in  rigid  body  modes  can  indicate  improper  constraint 
sets.  All  these  diagnostics  should  be  checked  where  applicable. 

Loads  often  provide  a  good  standard  with  which  to  validate  models.  A  set  of 
known  loads  that  provide  a  set  of  known  or  measured  displacements  for  the  actual 
structure  provide  a  benchmark  that  can  be  used  to  check  the  model  for  continuity, 
connectivity,  and  constraints.  Correlation  of  such  data  provides  confidence  that  the 
model  is  an  accurate  representation  of  the  real  structure.  Confidence  in  the  model  is 
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a  very  important  factor  in  finite  element  analysis,  since  there  can  be  errors  that  are 
not  easy  to  detect.  Another  method  of  providing  loads  to  run  a  check  on  a  model  is 
the  use  of  structural  influence  coefficients  using  point  loads  as  was  done  during  the 
creation  of  the  the  B-1A  model.  This  is  useful  if  there  are  sufficient  data  to  check 
against.  If  vibration  data  are  available,  from  a  ground  vibration  test  for  example,  a 
normal  modes  analysis  of  the  model  can  help  verify  the  stiffness  of  the  model  if  the 
mass  is  known  to  match. 

In  dynamic  problems,  mode  shapes  should  be  checked  thoroughly  by  generating 
plots.  Improper  stiffness  and  masses  will  often  show  up  as  unrealistic  mode  shapes. 
Also,  the  diagnostic  messages  that  are  provided  with  the  various  eigenvalue  solution 
methods  should  be  checked  to  insure  that  no  roots  have  been  skipped. 

Validating  a  model  can  require  a  great  deal  of  effort.  As  the  survey  results  reported 
in  Appendix  A  indicate,  Air  Force  agencies  receiving  models  from  contractors  often 
have  no  practical  choice  but  to  assume  that  the  contractor  has  created  a  good  model. 
It  can  be  argued  that  manufacturers  have  the  best  data  and  knowledge  of  the  structure 
and  so  the  models  they  create  ought  to  be  good.  Of  course,  a  major  goal  of  the  present 
effort  is  to  make  it  unnecessary  to  accept  models  on  faith,  by  requiring  evidence  of 
validation  along  with  delivery  of  models. 


5.5  Supporting  Documentation 

The  value  of  a  finite  element  model  depends  heavily  on  the  availability  of  supporting 
documentation,  especially  when  a  model  is  delivered  from  one  organization  to  another. 
Documentation  may  include  reports,  plots,  sketches,  and  comments  in  the  bulk  data 
deck. 


5.6  Mil-Standard  for  Delivery  of  Finite  Element  Models 

The  need  for  a  standard  to  require  developers  of  Air  Force  aircraft  to  deliver  the 
finite  element  models  that  they  generate  has  already  been  discussed  in  section  2.  In 
this  section  we  discuss  the  proposal  for  a  standard  in  more  detail.  The  Mil-Standard 
presented  in  Appendix  B  was  based  largely  on  Venkayya’s  proposal  [1]),  but  with 
some  additional  ideas  and  a  somewhat  different  arrangement. 

5.6.1  Background  on  Mil-Standards 

Typically  a  standard  imposes  requirements  and  performance  standards  and  recom¬ 
mends  techniques  for  compliance.  Structural  requirements  for  aircraft  are  contained 
in  two  basic  documents,  Mil-A-87221  and  Mil-Std-1530A.  A  Mil-Standard  for  the  ac¬ 
quisition  of  finite  element  models  should  ideally  be  a  separate  document,  although  it 
could  conceivably  be  made  part  of  Mil-A-87221,  during  its  next  review  and 
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update  cycle.  The  requirements  of  such  a  Mil-Standard  have  been  addressed  by 
the  Air  Force.  A  sample  Data  Item  Description  was  drafted  in  1985  [4]  and  addresses 
in  detail  the  type  of  data  that  must  be  supplied. 

Through  the  MIL-PRIME  program,  the  Air  Force  has  been  working  to  streamline 
the  acquisition  process  by  improving  the  quality  of  specifications  and  standards  ap¬ 
plied  to  individual  contracts.  The  goal  is  to  eliminate  overspecification  by  tailoring 
documents  to  specific  weapons  systems.  Each  MIL-PRIME  document  consists  of  a 
specification  or  standard  tailored  to  the  specific  situation.  An  associated  handbook 
contains  rationale,  guidance,  and  lessons  learned  for  each  requirement  and  its  associ¬ 
ated  verification.  By  the  end  of  1987,  fifty- four  MIL-PRIME  development  documents 
were  available  for  program  use  [13].  In  the  past,  delivery  of  finite  element  models  has 
generally  not  been  a  requirement,  even  though  the  contractor  may  have  been  paid  for 
the  work  involved.  If  such  delivery  is  to  made  a  requirement,  a  stringent  Mil-Standard 
must  be  developed  to  ensure  that  models  contain  all  the  documentation  needed  to 
insure  their  usefulness.  The  requirements  of  this  Mil-Standard  should  be  such  that  it 
would  not  require  or  even  accept  tailoring  to  an  individual  program.  The  temptation 
to  water  down  the  model  requirements  must  be  avoided. 

5.6.2  Comments  on  the  Mil-Standard 

Appendix  B  of  this  report  presents  a  Draft  Mil-Standard  on  Requirements  for  De¬ 
livery  of  Finite  Element  models.  The  Standard  was  formatted  along  the  lines  of 
Mil-Standard  1530.  This  document  would  of  course  be  subject  to  review  and  editing 
before  it  could  be  published  as  an  official  Mil-Standard. 

Typical  Mil-Standards  are  only  four  to  eight  pages  in  length.  The  Mil-Standard  in 
Appendix  B  was  deliberately  kept  short,  also.  Mil-Standards  are  meant  to  be  flexible 
documents,  to  be  tailored  to  the  needs  of  a  particular  contract. 

The  subjects  of  acoustic  cavity  analysis  and  electromagnetic  analysis,  were  omit¬ 
ted,  even  though  they  can  be  solved  with  finite  elements,  were  omitted  from  the 
Mil-Standard  because  they  are  not  relevant  to  aircraft  structures.  Neither  were  meta¬ 
models  (input  to  finite  element  pre-processors)  included  because  they  are  not  suitable 
for  standardization  at  this  time. 

5.6.3  Costs 

It  must  be  understood  that  these  requirements  will  impose  costs  upon  contractors 
which  will  ultimately  be  reflected  in  their  bids.  Superficially,  it  might  seem  that 
the  only  costs  involved  would  be  writing  a  tape,  bundling  up  some  documents,  and 
shipping  them,  and  these  would  be  nominal.  In  fact,  the  real  costs  would  result 
from  contractors’  perceptions  (real  or  imagined)  that  they  were  being  subject  to 
increased  exposure  and  liability.  They  would  thus  expend  extra  effort  in  verifying 
and  documenting  any  models  that  were  to  be  delivered. 
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It  is  very  difficult  to  quantify  such  costs.  They  would  certa  nly  be  considerably 
less  than  the  costs  that  would  be  expended  if  the  Air  Force  should  have  to  go  out 
on  contract  for  the  purpose  of  creating  a  finite  element  model  of  an  existing  system, 
which  has  happened. 

Another  relevant  point  is  the  benefits  that  would  accrue  to  both  the  contractor 
and  the  Air  Force  as  a  result  of  'hese  requirements,  aside  from  the  delivery  per  se. 
The  authors  know  from  long  experience  that  having  to  explain  a  model  to  a  colleague 
is  one  of  the  most  effective  ways  of  debugging  it.  This  is  sc  even  when  the  colleague 
merely  sits  and  listens.  Another  fact  of  life  is  that  developers,  having  invested  so  much 
energy  in  a  model,  tend  to  assume  it  is  complete  before  there  have  been  sufficient 
checks.  It  is  quite  likely  that  in  documenting  and  verifying  a  modM  in  preparation 
for  delivery,  contractors  would  discover  shortcomings  that  had  previously  not  come 
to  light.  Such  discoveries  could  prevent  potentially  catastrophic  problems  with  the 
models.  In  any  event,  the  additional  efforts  would  increase  the  contractor’s  confidence 
in  his  own  model. 

Another  way  to  approach  the  costs  issue  is  to  assume  for  a  moment  that  delivery 
requirements  had  been  in  effect  all  along  and  that  someone  was  proposing  eliminating 
them  in  order  to  save  money.  They  would  have  to  argue  that  contractors  would  bid 
lower  because  they  could  take  less  care  in  their  modeling  and  could  skip  some  of  the 
documentation  and  verification  efforts.  Such  arguments  would  not  likely  be  taken 
seriously.  This  would  be  especially  true  if  the  proposed  Model  Center  had  been  in 
existence  for  some  time,  and  if  models  delivered  by  contractors  had  been  used  to 
advantage  by  the  Air  Force. 
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6.  FEM-X  Database  Management  System 


FEM-X  is  the  finite  element  database  management  system  that  was  developed  as 
part  of  this  contract.  In  accordance  with  the  terms  of  the  contract,  the  delivered 
software  is  considered  a  prototype  version.  Thus  while  the  developers  have  taken 
great  pains  to  produce  a  robust  and  useful  system,  FEM-X,  like  any  substantial 
software  product,  needs  to  undergo  a  period  of  independent  or  beta  testing  to  flush 
out  errors  or  shortcomings.  Detailed  instructions  on  the  use  of  FEM-X  may  be  found 
in  the  accompanying  FEM-X  Ustr’s  Guide.  This  section  briefly  reviews  the  operation 
and  organization  of  FEM-X,  and  discusses  some  of  the  software  design  decisions  that 
were  made. 

The  software  is  intended  to  address  a  specific  need  in  finite  element  analysis:  the 
need  for  procedures  to  provide  storage,  identification,  and  tracking  of  finite  element 
models.  It  is  not  intended  to  compete  wFh  graphics  software  used  for  generation  and 
display  of  finite  element  models  and  therefore  does  not  provide  s,.ch  displays,  not  any 
X-Y  plots.1  Neither  does  FEM-X  do  any  significant  checking  of  finite  element  data. 
It  is  assumed  that  the  user  has  the  skill  and  the  resources  (e.g.,  a  computer  running 
NASTRAN)  to  perform  validation  tasks.  Because  it  provides  a  convenient  framework 
for  documentation  and  storage  of  models,  it  is  expected  that  FEM-X  will  encourage 
users  to  perform  and  document  validation  runs. 

Most  successful  software  packages  provide  users  with  a  framework  for  exercising 
their  own  creativity.  Examples  include  spreadsheets  with  formula-building  tools  and 
macro  languages,  NASTRAN  with  its  DMAP  matrix  manipulation  language  (which  is 
arguably  the  most  important  reason  for  NASTRAN’s  longevity),  or  ASTROS  with  its 
MAPOL  language,  user-callable  relational  database,  and  its  system  generation  utility. 
It  is  hoped  that  FEM-X  will  encourage  user  productivity  and  innovations  in  two  ways: 
First,  the  software  is  rather  flexible  in  that  it  provides  users  with  a  number  of  text 
fields  whose  names  suggest  what  the  contents  should  be,  but  nevertheless  allow  users 
wide  latitude  in  actually  entering  data.  Second,  the  use  of  CADDB  as  the  underlying 
database  manager  may  encourage  users  to  develop  applications  for  manipulation  of 
bulk  data  stored  in  FEM-X.  This  is  because  of  the  wide  range  of  options  available 
for  manipulating  CADDB  data  through  ICE  (the  interactive  interface  to  CADDB 
databases,  described  in  [14])  or  the  Fortran  interface. 

While  FEM-X  is  designed  to  be  usw-friendly,  it  is  also  meant  to  encourage  more 
discipline  on  the  part  of  its  users.  Finite  element  analysts,  like  software  developers, 
often  neglect  documentation  chores.  FEM-X  will  encourage  documentation  in  parallel 
with  development  or  modification  of  models.  For  users  of  and  developers  of  finite 
element  models,  FEM-X  will  provide  functionality  reminiscent  of  that  provided  by 

'But  because  it  works  under  the  X  Window  System,  FEM-X  will  harmonize  well  with  graphics 
software  that  also  runs  under  X.  Users  will  be  able  to  view  finite  element  graphics  in  one  window  and 
FEM-X  in  another,  on  the  same  screen.  Major  finite  element  graphics  packages  arc  iow  beginning 
to  provide  support  for  X . 
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Figure  7:  Hierarchy  of  Information  in  FEM-X 
CA.E  tools1  for  software  developers. 

The  primary  purpose  of  FEM-X  is  to  support  the  proposed  Air  Force  Finite  El¬ 
ement  Model  Center  (Section  7).  The  users  at  the  Center  will  not  be  expected  to 
create  finite  element  models,  although  they  may  modify  them.  However,  FEM-X 
should  also  be  useful  to  analysts  who  are  creating  models.  Its  provisions  for  doc¬ 
umentation  should  be  useful  for  keeping  a  work  log  and  for  maintaining  significant 
versions  of  their  models  that  are  generated  as  the  design  changes,  loads  change,  etc. 


6.1  Organization  of  Information  in  FEM-X 

The  information  in  the  FEM-X  database  is  organized  in  a  hierarchical  fashion,  as 
shown  in  Figure  7.  The  items  that  constitute  the  hierarchy  (systems,  components, 
versions,  and  variations)  are  explained  in  the  following  paragraphs.  Users  move  up 
and  down  the  hierarchy  and  are  always  located  at  a  particular  position  which  deter¬ 
mines  the  options  available  to  them.  That  is,  they  start  by  selecting  a  system,  then 
may  move  down  to  a  component,  down  to  a  version,  back  up  to  the  original  system 
level,  sideways  to  a  new  system,  etc. 

'Computed- Aided  Software  Engineering 
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6.1.1  Systems  and  Components  in  FEM-X 


FEM-X  is  designed  to  support  finite  element  analysts  who  are  working  with  models 
of  airframes.  Although  it  is  hoped  and  expected  that  the  software  will  be  useful 
to  engineers  working  with  other  kinds  of  FE  models,  there  is  one  aspect  of  aircraft 
models  that  had  particular  influence  on  the  design  of  the  software.  This  is  the  fact 
that  models  of  individual  sections  or  “components”  of  aircraft  are  more  common  than 
single  models  of  an  entire  aircraft.  Therefore,  finite  element  models  in  FEM-X  are 
assumed  to  represent  a  single  component,  and  components  are  grouped  under  the 
heading  of  a  “system.”  Thus,  for  example,  the  database  might  contain  a  number 
of  models  of  portions  of  the  Bl-B  airframe.  Under  “systems,”  there  would  be  an 
entry  called  “Bl-B.”  In  addition  to  some  brief  text  about  the  Bl-B,  there  could  be  a 
number  of  component  entries  such  as  “Wing  Carry- through,”  or  “Forward  Landing 
Gear.”  For  each  of  these  components,  there  would  not  only  be  a  finite  element  model 
but  a  wide  variety  of  descriptive  information  as  well. 

The  system-component  arrangement  does  not  preclude  a  single  model  of  an  entire 
aircraft,  or  any  other  structure.  In  this  case,  the  user  would  have  a  system  with  just 
one  component  which  would  constitute  the  entire  model. 

6.1.2  Versions  and  Variations  in  FEM-X 

In  working  with  finite  element  models,  analysts  invariably  make  a  number  of  changes 
in  a  model.  Some  changes  are  for  debugging  purposes.  Other  changes  are  part  of  the 
normal  course  of  developing  and  checking  out  a  model  (e.g.,  an  initial  static  analysis 
may  be  used  to  verify  the  “sanity”  of  the  model,  perhaps  followed  by  calculation 
of  a  few  natural  frequencies,  followed  by  more  natural  frequencies).  Some  changes, 
especially  those  made  for  debugging  purposes,  are  transient  in  nature  and  are  properly 
discarded  after  they  are  run  through  the  analysis  code.  Other  changes  may  not 
have  much  bearing  on  the  final  purpose  of  the  model,  but  would  be  of  some  interest 
for  future  review  of  the  steps  undertaken  by  the  analyst.  Other  changes  warrant 
careful  documentation,  such  as  new  load  conditions,  design  changes,  etc.  FEM-X 
provides  two  modes  for  handling  the  various  kinds  of  model  changes  that  may  be 
made:  versions  and  variations. 

A  version  is  a  substantial  change  in  a  model,  typically  undertaken  for  engineering 
purposes.  A  variation  is  a  minor  change,  such  as  a  local  refinement,  a  change  in 
boundary  conditions,  etc.  It  is  entirely  up  to  the  user  to  classify  a  particular  change 
as  a  version  or  a  variation. 


6.1.3  Results  and  References  in  FEM-X 

FEM-X  provides  for  text  entries  under  the  heading  “Results.”  It  is  expected  that 
these  fields  will  be  used  for  entry  of  summary  remarks  about  the  results  produced  by 
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a  particular  FE  model  (e.g.,  maximum  stresses,  natural  frequencies,  etc.).  Users  may 
also  wish  to  use  the  cut-and-paste  facility  of  X  to  extract  small  portions  of  the  output 
file  of  the  finite  element  code,  such  as  eigenvalue  tables  or  the  summary  information 
that  appears  when  X-Y  output  is  requested  in  NASTRAN  and  place  these  portions 
in  the  “Results”  field 

As  an  example  of  the  use  of  the  “results”  field,  consider  a  user  who  was  computing 
natural  frequencies  and  mode  shapes  of  a  structure.  FEM-X  would  je  open  in  one 
window  on  the  screen.  The  user  could  open  another  window  and  scroll  through 
NASTRAN’s  “print”  file  in  another.  Upon  reaching  the  eigenvalue  summary  table,  he 
would  use  the  mouse  to  cut  the  frequencies  from  the  NASTRAN  output  file  and  paste 
them  into  the  FEM-X  “results”  field.  He  would  then  open  a  post-processing  program 
in  another  window  to  display  deformed  shape  plots  for  several  natural  frequencies.  He 
would  use  these  displays  to  characterize  each  mode  and  enter  remarks  such  as  “first 
bending  mode”  next  to  the  corresponding  natural  frequency  in  the  “results”  window. 

An  area  labelled  “references”  is  provided  for  entry  of  information  about  supporting 
documents  such  as  drawings,  reports.  It  could  also  contain  brief  notes,  transcripts  of 
telephone  conversations,  etc. 


6.1.4  Scripts 

CADDB  is  a  relational  database  offering  sophisticated  means  for  users  to  extract, 
view,  or  compare  data.  There  are  two  ways  for  users  to  perform  these  functions:  by 
writing  Fortran  or  C  code  that  calls  library  routines  that  are  provided  in  object  code 
format  with  the  ASTROS  distribution  (and  described  in  Volume  IV  of  [2]),  and  by 
using  the  interactive  interface  code  called  ICE  (Interactive  CADDB  Environment, 
[14]).  ICE  implements  a  query  language  called  CQL  (CADDB  Query  Language), 
a  counterpart  of  the  well-known  SQL  language  for  business  database  applications. 
Because  sequences  of  CQL  commands  can  be  quite  complex,  users  often  enter  them  in 
script  files  and  play  them  through  ICE  in  a  semi-interactive  mode.  FEM-X  provides 
a  mechanism  for  users  to  create,  store,  and  execute  ICE  scripts.  The  users  have 
complete  liberty  to  write  any  ICE  script.  FEM-X  does  not  check  the  syntax  or 
usefulness  of  a  user’s  script;  it  merely  provides  means  to  store,  identify,  and  execute 
scripts.  The  uses  for  which  scripts  might  be  employed  are  limited  only  by  users’s 
imaginations.  However,  it  is  expected  that  scripts  will  be  used  primarily  to  extract 
portions,  or  subsets,  of  a  bulk  data  file.  Typically,  a  user  script  would  include  a  SET 
INTERFACE  command  for  the  purpose  of  writing  selected  data  to  an  ASCII  file.  This 
file  could  then  be  edited  and  used  to  refine  or  modify  a  model. 

Following  is  an  example  of  a  hypothetical  script  file  whose  purpose  is  to  iden¬ 
tify  and  write  out  all  of  the  nodes  and  elements  (specifically,  GRID,  CQUAD4,  and 
CTRIA3  records)  near  the  engine  mount  of  an  aircraft  wing  model.  Although  the 
CQL  commands  appearing  here  are  fairly  self-explanatory,  readers  unfamiliar  with 
ICE  will  want  to  consult  the  ICE  manual  [14]  for  complete  explanations  of  what 
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each  command  does.  The  commands  are  numbered  for  reference  in  the  following 
discussion: 

1.  CREATE  VIEW  ENGiwtGRIDS  AS 

SELECT  ID,X,Y ,Z  FROM  GRID  WHERE 
X  >  143.2  AND  X  <  157.8; 

2.  SET  INTERFACE  TO  ’ ENGINE. GRID’ ; 

3.  INTERFACE  ON; 

4.  INTERFACE  FORMAT  » (’ ’GRID’ \I12,8X,3F8.4) * ; 

5.  SELECT  ID,X,Y,Z  FROM  ENGINEGRIDS; 

6.  SET  INTERFACE  TO  *  ENGINE. CQUAD4’ ; 

7.  INTERFACE  FORMAT  ' (» ,CqUAD4> ’ , T9, 618)  ’ ; 

8.  SELECT  EID,PID,G1 ,G2 ,G3 ,G4  FROM  CQUAD4  WHERE 

G1  IN  (SELECT  ID  FROM  ENGINEGRIDS)  OR 
G2  IN  (SELECT  ID  FROM  ENGINEGRIDS)  OR 
G3  IN  (SELECT  ID  FROM  ENGINEGRIDS)  OR 
G4  IN  (SELECT  ID  FROM  ENGINEGRIDS) ; 

9.  SET  INTERFACE  TO  ’ ENGINE. CTRIA3 ’ ; 

10.  INTERFACE  FORMAT  ’ (’ ’CTRIA3’ * , T9, 518) ' ; 

11.  SELECT  EID,PID,G1,G2,G3  FROM  CTRIA3  WHERE 

G1  IN  (SELECT  ID  FROM  ENGINEGRIDS)  OR 
G2  IN  (SELECT  ID  FROM  ENGINEGRIDS)  OR 
G3  IN  (SELECT  ID  FROM  ENGINEGRIDS) ; 

The  region  near  the  engine  mount  is  identified  by  143.2  <  x  <  157.8.  Line  1 
creates  an  entity  called  ENGINEGRIDS  which  consists  of  the  ID  and  coordinates  of 
all  the  nodes  that  lie  in  that  range.  Line  2  opens  a  file  that  will  receive  selected 
data,  line  3  activates  writing  to  this  file,  and  line  4  is  a  Fortran  format  statement  for 
writing  GRID  data.  Line  5  causes  all  the  data  in  ENGINEGRIDS  to  be  written  to 
the  interface  file.  Lines  7  through  1 1  extract  all  the  QUAD4  elements  that  have  at 
least  one  node  in  ENGINEGRIDS,  and  the  final  set  does  the  same  for  TRIA3  elements. 

Two  shortcomings  of  ICE  may  be  noted  in  passing.  First,  there  is  no  provision  for 
comment  lines.  Second,  each  INTERFACE  FORMAT  statement  causes  any  information 
previously  written  to  the  interface  file  to  be  lost.  Hence  the  example  above  was  set 
up  to  write  to  three  different  files.  The  authors  view  the  latter  situation  as  a  bug  in 
ICE  which  should  be  fixed. 

As  the  foregoing  example  indicates,  scripts  can  be  rather  complex.  It  is  expected 
that  users  will  develop  scripts  interactively,  and  only  when  they  are  seen  to  produce 
the  required  results  will  they  be  entered  in  FEM-X.  FEM-X,  ICE,  and  the  X  Window 
environment  will  provide  users  with  a  number  of  options  for  developing  scripts.  One 
scenario  is  as  follows:  the  user  types  ICE  commands  into  the  window  provided  for 
FEM-X  scripts.  (This  window  provides  virtually  all  the  features  of  the  xedit  screen 
editor  that  accompanies  X.)  When  the  user  wants  to  try  the  script,  he  simply  picks 
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the  EXECUTE  button  on  the  screen,  at  which  time  his  script  is  played  through  ICE 
and  the  results  shown  on  an  additional  window  that  is  created  for  that  purpose.  If 
the  results  are  not  satisfactory,  the  user  can  edit  the  script  and  repeat  its  execution. 
In  another  scenario,  the  user  can  be  running  ICE  in  a  separate  xterm  window,  having 
issued  the  SET  ARCHIVE  command  to  cause  all  commands  that  are  entered  to  be  saved 
on  a  file.  Once  satisfied  with  the  results,  the  user  can  insert  the  archive  file  into  the 
FEM-X  script  window  with  a  simple  command.  Unwanted  lines  can  then  be  removed 
from  the  script. 

6.2  Finite  Element  Model  Data 

Section  5  of  this  report  stipulated  that  COSMIC  NASTRAN  should  be  the  format  in 
which  contractors  deliver  finite  element  model  data  to  the  Air  Force.  However,  many 
models  exist  in  ASTROS  and  MSC/NASTRAN  data  formats  as  well.  Therefore, 
FEM-X  has  been  designed  to  support  all  three  of  these  formats.  All  finite  element 
model  data  that  are  entered  into  FEM-X  are  tagged  to  indicate  whether  it  conforms 
to  ASTROS,  COSMIC  NASTRAN,  or  MSC/NASTRAN  format.  FEM-X  does  a 
modest  amount  of  checking  of  bulk  data  that  are  entered,  equivalent  to  the  checking 
that  ASTROS  or  NASTRAN  do  in  their  first  pass  over  the  bulk  data:  checks  for 
required  fields,  data  type,  and  limited  checks  of  values  (such  as  numbers  that  are 
supposed  to  be  positive). 


6.2.1  Prefaces 

All  three  finite  element  codes  accept  data  from  ASCII  files  in  very  similar  formats. 
Preliminary  information,  (executive  control,  case  control,  etc.)  appears  in  relatively 
free  format,  followed  by  the  actual  finite  element  model  data  in  bulk  data  format 
(mostly  numeric,  entered  in  8-character  fields).  We  have  grouped  this  preliminary 
information  under  the  heading  “prefaces”  in  FEM-X.  Prefaces  are  stored  separately 
from  bulk  data  and  are  also  tagged  as  having  either  ASTROS,  COSMIC  NASTRAN, 
or  MSC/NASTRAN  format.  FEM-X  does  not  perform  any  kind  of  checking  to  vali¬ 
date  preface  data,  however. 

The  contents  of  prefaces  for  the  various  finite  element  packages  are  as  follows: 


ASTROS 


DEBUG  packet 

Debug  output  control 

MAPOL  packet 

MAPOL  matrix  language  source  code 

SOLUTION  packet 

selections  of  solution  type,  loads,  support  conditions, 
output  requests,  solution  methods,  etc. 
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COSMIC  NASTRAN 


NASTRAN  card 

Miscellaneous  operating  parameters 

Executive  control 

Choice  of  solution  type,  etc. 

Substructure  control 

Control  of  substructuring  operations 

Case  control 

Selection  of  loads,  support  conditions,  output  re- 

quests,  solution  methods,  etc. 

MSC/NASTRAN  (version  65  and  earlier) 


NASTRAN  card 

Miscellaneous  operating  parameters 

Executive  control 

Choice  of  solution  type,  etc. 

Case  control 

Selection  of  loads,  support  conditions,  output  re¬ 
quests,  solution  methods,  etc. 

MSC/NASTRAN  (version  66  and  later) 


NASTRAN  card 

Miscellaneous  operating  parameters 

File  management  section 

Database  control 

Executive  control 

Choice  of  solution  type,  etc. 

Case  control 

Selection  of  loads,  support  conditions,  output  re- 

quests,  solution  methods,  etc. 

6.2.2  Entry  of  New  Models 

In  order  to  enter  a  new  finite  element  model  into  FEM-X,  the  user  provides  a  few 
simple  items  of  information  by  filling  in  blanks  in  a  screen  like  that  shown  in  Figure 
8.  The  software  then  reads  the  file  indicated  by  the  user  and  splits  it  into  a  preface 
(as  explained  in  Section  6.2.1)  and  the  actual  bulk  data.  The  bulk  data  are  read 
into  CADDB  relations  by  executing  a  special  “rump”  version  of  ASTROS.  There  are 
three  special  versions  of  ASTROS:  one  for  ASTROS  data,  one  for  COSMIC  NAS¬ 
TRAN,  and  one  for  MSC/NASTRAN.  The  word  “rump”  indicates  that  the  standard 
MAPOL  sequence  of  ASTROS  has  been  replaced  with  a  truncated  version  that  does 
nothing  more  than  read,  check,  and  store  bulk  data.  Input  values  are  checked  with 
respect  to  type  and  in  some  cases  ranges  of  allowable  values.  The  three  versions  of 
ASTROS  were  generated  using  the  SYSGEN  capability  of  ASTROS,  which  creates 
executable  code  and  a  system  database  based  on  descriptive  files  that  may  be  modi¬ 
fied  by  knowledgeable  users.  Complete  descriptions  of  all  the  bulk  data  cards  possible 
in  COSMIC  NASTRAN  and  MSC/NASTRAN  were  coded  into  these  files,  along  with 
relational  schema  used  to  store  this  data.  More  details  on  this  process  may  be  found 
in  the  FEM-X  User’s  Guide. 


6.2.3  Extraction  of  Bulk  Data 

Extraction  of  bulk  data  is  available  through  a  screen  designed  for  that  purpose.  “Ex¬ 
traction"  simply  means  writing  the  bulk  data  to  an  ASCII  file,  along  with  an  optional 
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Figure  8:  FEM-X  Screen  for  Entry  of  a  New  Finite  Element  Model 

preface.  The  user  decides  what  to  do  with  the  ASCII  file  after  it  is  created,  but  pre¬ 
sumably  it  will  serve  as  input  to  NASTRAN  or  ASTROS,  perhaps  being  edited  first. 
(After  editing  and  running  the  bulk  data,  the  user  may  choose  to  re-enter  it  in  the 
database  as  a  version,  variation,  or  even  a  new  component  model.  The  bulk  data  that 
will  be  provided  is  determined  by  the  user’s  current  context  or  position  in  the  hier¬ 
archy  (i.e.,  what  component,  version,  etc.,  is  currently  accessed).  The  user  is  allowed 
to  select  a  preface  from  the  list  of  prefaces,  or  to  obtain  the  bulk  data  without  any 
preface.  The  user  is  also  offered  a  translation  option,  and  two  formatting  options  for 
MSC/NASTRAN  files:  space  or  tab  delimiters,  and  explicit  continuation  symbols  or 
implied  continuations. 

6.2.4  Translation  of  Bulk  Data 

As  a  convenience  to  users,  a  translator  function  is  provided  with  FEM-X.  Users  can 
request  that  bulk  data  be  translated  from  any  of  the  three  supported  formats  to  any 
of  the  others.  Preface  data  are  not  translated.  Not  all  data  types  are  supported 
by  all  three  codes.  When  there  is  some  ambiguity  or  an  assumption  to  be  made, 
the  translator  makes  a  choice  and  enters  a  note  in  a  commentary  file.  When  no 
translation  can  be  performed,  the  translator  simply  skips  the  data,  enters  a  note,  and 
proceeds.  The  choices  made  by  the  translator  regarding  individual  record  types  as 
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well  as  individual  fields  types  are  governed  by  a  “template  file”  which  can  be  modified 
by  careful  users  to  change  the  way  certain  records  or  fields  are  translated,  or  to  update 
the  translator  in  response  to  release  of  a  new  version  of  NASTRAN  or  ASTROS. 

The  translator  is  built  into  FEM-X  and  is  also  available  in  a  stand-alone  version 
called  TRANSNAS.  Detailed  information  on  the  translator  may  be  found  in  the 
accompanying  FEM-X  User’s  Guide. 

6.3  Design  Decisions  in  the  Development  of  FEM-X 

The  following  discussion  centers  on  some  of  the  issues  and  policies  that  came  up  prior 
to  and  during  the  development  of  FEM-X. 

Two  software  systems  were  chosen  for  use  with  FEM-X:  CADDB  for  database 
management  and  the  X  Window  System  for  the  user  interface.  Since  these  choices 
were  so  important  for  the  development  of  FEM-X,  they  are  discussed  in  some  detail 
here. 

6.3.1  Database  Software 

FEM-X  is  principally  a  database  application.  Its  basic  function  is  to  store,  retrieve, 
and  display  information  related  to  finite  element  models,  as  well  as  the  bulk  data 
for  the  models.  The  choices  available  at  the  time  this  project  was  initiated  were  as 
follows: 

1.  Use  a  commercial  database  package  such  as  Oracle. 

2.  Write  our  own  database  software. 

3.  Use  CADDB,  the  database  software  written  as  part  of  the  ASTROS  [2]  devel¬ 
opment  project. 

It  was  not  necessary  to  choose  the  same  database  software  or  approach  for  these  two 
classes  of  information;  thus,  the  approach  to  storing  text  data  is  discussed  separately 
from  the  approach  to  storing  bulk  data.  For  both  purposes,  commercial  database 
software  was  considered  undesirable  because  of  the  added  cost,  and  because  it  would 
be  a  hindrance  to  distribution  of  FEM-X  (i.e.,  there  would  be  license  agreements 
and  fees  both  for  the  development  work  and  for  each  distributed  copy  of  the  final 
product).  It  seemed  unreasonable  to  expend  resources  on  writing  our  own  software  if 
existing  software  could  be  used.  CADDB  was  already  being  used  to  store  bulk  data 
for  ASTROS,  and  it  appeared  to  offer  reasonable  facilities  for  storing  text  data  as  well. 
CADDB  was  the  leading  candidate  because  (1)  it  is  Air  Force  property,  controlled  by 
the  same  organization  that  will  control  FEM-X  (Wright  Laboratory/Flight  Dynamics 
Directorate),  (2)  it  seemed  to  offer  the  required  capabilities,  and  (3)  it  had  already 
been  ported  to  several  computers,  and  it  was  expected  that  subsequent  ports  would 
not  be  difficult. 


40 


Text  Data 


In  hindsight,  custom  database  software  for  text  strings  might  have  been  just  as  good 
a  choice  as  CADDB  for  storing  text  data.  This  statement  is  based  on  the  following 
considerations: 

1.  The  database  operations  required  by  FEM-X  are  not  particularly  complicated. 

2.  It  is  somewhat  awkward  (from  a  programming  point  of  view)  to  store  and 
retrieve  long  text  strings  (i.e.,  paragraphs)  using  CADDB. 

3.  Although  CADDB  functions  correctly  when  properly  utilized,  with  only  very 
minor  exceptions,  it  has  an  unfortunate  tendency  to  crash  or  corrupt  the  user’s 
database  when  utilized  improperly  (i.e.,  when  illegal  values  are  passed  to  CADDB 
subroutines). 

4.  CADDB  generates  database  files  that  seem  excessive  in  size,  i.e.,  their  size  is  a 
large  multiple  of  the  number  of  bytes  of  actual  data  they  contain. 

The  most  likely  alternative  to  CADDB  would  be  storage  of  text  data  in  ASCII  files, 
relying  on  the  Unix  hierarchical  file  system  for  organization  of  these  files.  But  there 
would  have  been  drawbacks  with  this  approach,  also,  mainly  the  proliferation  of  a 
large  number  of  small  files  in  user  directories,  and  the  increased  likelihood  that  files 
would  be  lost  because  users  or  system  managers  would  not  recognize  them  and  would 
delete  them. 

Bulk  Data 

FEM-X  has  been  programmed  for  storage  of  bulk  data  in  CADDB  relations.  The 
reasons  for  this  choice  are  as  follows: 

1.  Users  can  use  ICE  to  query  or  manipulate  the  bulk  data  as  they  see  fit.  Users 
may  compile  sequences  of  ICE  commands  into  files  called  “scripts”  which  may 
be  retained  in  the  FEM-X  database  (Section  6.1.4).  It  is  expected  that  users 
will  make  use  of  scripts  to  identify  particular  portions  of  an  aircraft  structure, 
but  other  uses  may  be  found  as  well. 

2.  Advanced  users  may  wish  to  write  Fortran  programs  that  interface  to  the 
CADDB  database.  For  example,  a  simple  plot  program  was  written  to  display 
a  model  in  a  FEM-X  database  in  an  X  Window.  This  program  is  documented 
in  the  FEM-X  User’s  Guide. 

There  are  drawbacks  to  this  approach,  however: 
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1.  First,  user  comments  are  lost  when  bulk  data  are  converted  to  CADDB  format. 
However,  our  policy  is  that  descriptive  data  belong  in  the  FEM-X  database 
where  it  can  be  reviewed  and  edited  conveniently.  Comments  from  the  bulk 
data  should  be  copied  into  the  windows  provided  for  commentary.  General 
commentary  can  be  entered  in  the  descriptive  text  fields  provided  for  individual 
components.  Comments  relative  to  particular  sets  of  cards  can  be  handled  by 
making  subsets  out  of  those  card  sets,  using  scripts  (Section  6.1.4)  and  entering 
the  commentary  in  the  descriptive  fields  provided  for  scripts.  Users  can  open 
the  ASCII  bulk  data  file  in  one  window  and  FEM-X  in  another.  Using  the 
mouse,  they  can  cut  comments  out  of  the  bulk  data  and  paste  it  into  FEM-X 
rather  easily. 

2.  When  a  user  wants  to  reconstitute  an  ASCII  bulk  data  file  from  an  FEM-X 
database,  the  file  that  is  written  will  not  be  identical  to  the  original  from  which 
the  database  version  was  generated.  We  expect  that  the  differences  will  be 
cosmetic  (field  alignment,  continuation  symbols,  etc.)  and  that  the  data  will 
be  identical  in  terms  of  the  results  that  NASTRAN  or  ASTROS  produce  when 
operating  on  that  data.  However,  the  following  problems  could  occur: 

(a)  At  present,  FEM-X  writes  only  single  fields  (8  characters),  even  though 
the  data  may  have  been  entered  using  NASTRAN’s  or  ASTROS’  double- 
field  (16  character)  option.  To  counteract  possible  loss,  code  is  set  up  to 
provide  maximum  precision  for  floating-point  data  within  eight  characters. 
At  worst,  three  significant  digits  are  provided  (e.g.,  —1.234567  x  10~12 
would  be  written  as  - .  123-13).  This  worst  case  only  occurs  with  negative 
numbers  smaller  than  10-10  in  magnitude.  Most  engineering  data  are  not 
accurate  beyond  three  digits,  so  there  should  be  no  problem  in  the  vast 
majority  of  cases.  Usually,  extra  precision  in  input  data  is  required  only 
for  matrix  input  (GENEL,  DTI,  and  DMI  cards).  This  consideration  plus 
the  complexity  of  these  cards  led  us  to  define  all  the  data  on  these  card 
types  in  COSMIC  and  MSC/NASTRAN  as  character  data.  For  such  cards, 
the  real  numbers  will  be  stored  as  ASCII  characters  thus  eliminating  any 
truncation  problems. 

(b)  There  is  a  wide  variety  of  card  types,  and  some  of  the  card  types  allow 
for  a  variety  of  data  configurations.  Although  the  code  has  been  tested 
extensively,  it  is  possible  that  some  obscure  card  configurations  may  be 
improperly  handled. 

There  is  a  very  small  probability  that  significant  data  would  be  lost  by  the  format 
translation  process.  None  of  the  models  that  have  been  exercised  with  FEM-X  to  date 
have  presented  any  such  problem.  Therefore  it  has  been  decided  to  retain  the  original 
bulk  data  file  in  addition  to  the  CADDB  relations.  The  prototype  version  of  FEM-X, 
as  delivered  with  this  report,  offers  users  a  choice  of  two  methods  of  extracting  bulk 
data  from  the  database  for  use  with  NASTRAN  or  ASTROS.  They  can  dther  request 
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that  the  bulk  data  in  the  database  be  written  to  a  file  of  their  choice,  or  that  the 
original  bulk  data  file  be  copied  to  their  file. 

ASTROS,  in  addition  to  reading  ASCII  files,  writes  its  bulk  data  on  CADDB 
databases.  It  would  be  possible  to  make  use  of  existing  ASTROS  bulk  data  in  a 
CADDB  database,  but  we  will  not  do  so.  The  reason  is  that  we  would  either  have  to 
use  the  existing  database  that  ASTROS  created,  adding  our  own  descriptive  entities  to 
that  database,  or  create  our  own  database  and  copy  all  the  bulk  data  relations  from  the 
ASTROS  user  database  to  our  new  database.  The  former  seems  inadvisable  because 
we  would  have  one  database  with  two  software  packages  manipulating  it  (ASTROS 
and  FEM-X),  with  the  attendant  danger  that  the  database  will  be  destroyed  or  moved, 
and  the  latter  is  awkward  because  there  is  no  simple  COPY  function  that  copies  a 
whole  entity  from  one  DB  to  another. 

In  summary,  the  main  consideration  that  favors  CADDB  for  storing  bulk  data  is 
the  flexibility  offered  by  the  interactive  query  language  that  is  implemented  in  ICE, 
and  by  the  Fortran  subroutine  library.  These  factors  enhance  the  opportunities  for 
creative  users  to  generate  new  capabilities  that  build  on  FEM-X.  Of  course,  only 
time  will  tell  whether  such  extensions  will  be  developed. 

6.4  The  X  Window  System 

The  second  critical  choice  was  the  use  of  the  X  Window  System1  for  the  user  interface. 
The  alternative  to  X  or  another  window  system  would  have  been  a  command  line 
interface  such  as  that  provided  with  ICE.  The  X  Window  System  was  chosen  became 
windowing  systems  had  become  very  popular  with  Macintosh  users  and  were  starting 
to  become  available  for  IBM-type  personal  computers,  engineering  workstations,  mini¬ 
computers,  and  even  Cray  supercomputers.  This  popularity  was  not  simply  due  to 
the  “warm  feeling”  experienced  by  users  of  window  systems,  but  was  in  fact  a  matter 
of  genuine  productivity  gains.  Any  Macintosh  user  knows  the  benefits  of  a  windowing 
system: 

•  Instead  of  consulting  a  manual  or  searching  one’s  memory  to  decide  what  to 
do  next,  one  simply  points  and  clicks  at  symbols  on  the  screen  that  show  what 

lX  Window  System  is  a  trademark  of  the  Massachusetts  Institute  of  Technology.  The  X  Consor¬ 
tium,  the  organization  responsible  for  the  development  and  distribution  of  the  X  Window  System, 
requests  that  the  following  names  be  used  when  referring  to  this  software: 

X  Window  System 
X  Version  1 1 

X  Window  System,  Version  11 
Xll 

The  best  reference  work  is  the  series  by  O’Reilly  and  associates  [3].  Volume  III,  X  Window  System 
User’s  Guide  is  best  for  these  who  will  be  users,  not  programmers.  Computer  magazines  are  also  a 
good  source  of  information  about  the  X  Window  System. 


43 


actions  are  available  and  meaningful  in  the  present  context.  A  “help”  button 
is  always  available  in  well-designed  applications  to  assist  users  when  they  are 
stuck.  Erroneous  entries  are  met  with  a  friendly  indication  that  something  is 
wrong. 

•  Multiple  overlapping  windows  can  be  open  on  the  screen.  Users  can  thus  refer 
back  and  forth  between  windows  showing  related  documents  or  information.  A 
“cut  and  paste”  facility  allows  users  to  copy  text  fields  between  applications 
that  support  this  facility  (such  as  FEM-X),  even  though  the  applications  may 
be  running  on  different  host  computers. 

Very  little  prescience  is  required  to  project  a  time  in  the  near  future  when  users  will 
demand  and  expect  window  environments  and  will  have  lost  patience  with  command- 
driven  software.  Thus  the  use  of  a  windowing  system  for  FEM-X  could  be  expected 
to  extend  its  useful  life  considerably. 

Computer  manufacturers  had  begun  to  offer  proprietary  windowing  systems  tied 
to  their  own  hardware,  such  as  Sunview  on  Sun  workstations  or  Workspace  on  Silicon 
Graphics  workstations.  The  advantages  of  X  over  these  proprietary  systems  are  as 
follows: 

1.  X  was  designed  to  work  on  virtually  any  computer  that  provides  a  bitmapped 
graphics  display  and  one  of  several  networking  protocols  (TCP/IP,  DECnet). 
Applications  that  use  X  could,  at  least  in  theory,  run  on  any  machine  to  which 
X  had  been  ported. 

2.  X  was  designed  from  the  beginning  to  function  in  a  network  environment.  It  is 
possible  to  run  an  application  (the  “client”)  on  one  machine  and  the  associated 
display  on  another  (the  “server”).1  No  effort  is  required  on  the  part  of  the 
application  programmer  to  take  advantage  of  this  facility.  The  display  for  an 
application  can  be  made  to  appear  on  any  properly  equipped  workstation  with 
no  modification  or  recompilation  of  the  application  source  code  required. 

The  X  Window  System  is  freely  available  from  MIT  in  source  code  format,  with 
machine-specific  display  server  code  provided  for  most  major  workstations.  CSA 
chose  to  use  this  version  of  X  in  writing  FEM-X. 

Increasingly,  vendors  are  providing  software  environments  that  are  compliant  with 
the  X  specification  (principally,  Open  Look  on  Sun  workstations  and  Motif  on  Digital 
Equipment  workstations).  The  proliferation  of  the  X  Window  System  in  the  worksta¬ 
tion  world  has  validated  our  decision  to  use  X.  One  need  only  look  around  the  Flight 
Dynamics  Directorate  or  the  ASD  Computer  to  see  the  predominance  of  window  sys¬ 
tems,  more  and  more  of  which  are  based  on  the  X  Window  System.  The  choice  of  X 

Unfortunately,  many  people  think  of  the  “server”  as  the  machine  doing  the  computing  and  the 
“client”  as  the  machine  doing  the  display.  In  X  terminology,  these  terms  have  the  opposite  meaning. 
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has  also  taken  its  toll  on  this  project,  however.  Considerable  resources  were  expended 
early  on  in  learning  to  program  with  X.  Initially,  Release  3  of  Version  11  of  X  was 
used,  and  there  were  some  difficulties  with  that  release.  Later,  XI 1  Release  4  was 
adopted,  and  these  difficulties  were  cleared  up.  Also,  until  all  proprietary  window 
systems  achieve  compliance  with  XI 1  R4,  it  may  not  be  possible  to  install  FEM-X  on 
some  workstations.  For  example,  the  IBM  RS/6000  workstation  currently  provides  a 
version  of  Motif  that  is  not  compliant  with  X,  but  the  next  release,  due  in  the  first 
half  of  1991,  is  supposed  to  be  compliant. 

6.5  Computers  that  can  run  FEM-X 

This  section  discusses  the  kinds  of  computers  on  which  FEM-X  can  be  run,  in  terms 
of  both  hardware  and  supporting  software.  As  indicated  in  the  preceding  discussion, 
the  X  Window  System  makes  it  possible  to  run  FEM-X  on  one  machine  and  the 
display  on  another,  with  no  changes  to  the  code.  This  allows  many  choices  in  a  large 
organization  like  WRDC.  The  ASD  computer  center  has  an  extensive  network  that 
connects  a  number  of  workstations  and  computers  both  at  Building  676  and  in  other 
buildings.  Seated  at  a  workstation  in  the  Flight  Dynamics  Laboratory,  for  example, 
a  user  can  run  an  application  on  a  computer  at  the  Computer  Center,  a  half  mile 
away,  and  see  the  application’s  display  in  front  of  him.  This  works  well  in  practice, 
not  just  in  theory. 

Devices  called  X  Terminals  have  been  available  for  the  past  2  to  3  years  and 
are  currently  priced  from  $995  up.  These  are  bit-mapped  display  terminals  that 
incorporate  the  X  server  software  in  local  firmware  but  have  no  other  local  comput¬ 
ing  capabilities  nor  any  local  disks.  They  must  be  connected  over  a  network  to  a 
workstation,  mini-computer,  or  mainframe  running  X  applications  (“clients”).  An 
X  Terminal  can  be  thought  of  as  a  compromise  between  a  “dumb  terminal”  like  a 
VT100  and  a  low-end  workstation  like  a  SPARCstation.  CSA  used  an  X  Terminal 
for  development  of  FEM-X  and  found  no  problem  in  running  it  using  this  terminal, 
except  that  it  is  somewhat  slow. 

A  computer  on  which  FEM-X  is  to  be  installed  as  a  client  must  have  the  following 
attributes: 


Operating  system 

Unix 

Compilers 

C  (standard  with  all  Unix  systems) 

Fortran  (f77) 

Database 

ASTROS  object  library 

Window  System 

Compatible  with  XI 1,  Release  4 

Main  memory 

Requirement  unknown,  but  unlikely  to  be 
a  problem  in  practice 

Disk  storage 

100M  desirable 

Any  display  device  (workstation  or  X  terr  inal)  must  be  capable  of  handling  input  to 
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and  output  from  an  application  written  for  XI 1,  Release  4.  CSA’s  X  Terminal,  which 
implements  XI 1  R3  server  software,  handles  FEM-X  and  other  R4  displays  with  no 
problem. 
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7.  Plan  of  Operation  for  the  Finite  Element  Model 
Center 

This  plan  of  operation  provides  detailed  projections  for  the  establishment  and  opera¬ 
tion  of  the  Air  Force  Finite  Element  Center.  The  purpose  of  the  Finite  Element  Model 
Center  is  to  collect,  evaluate,  store,  and  disseminate  finite  element  model  information 
to  qualified  users,  primarily  to  other  Air  Force  organizations  or  their  contractors.  The 
overall  objective  of  the  Center  is  to  ensure  that  finite  element  models  of  aircraft  and 
aerospace  structures  are  made  available  in  a  form  that  maximizes  their  usefulness  to 
these  users.  It  will  support  Logistics  Centers  with  respect  to  modifications  or  repair 
and  maintenance  of  operational  aircraft.  The  Center  will  also  provide  assistance  to 
SPO’s  in  enforcing  the  standards  for  delivery  of  finite  element  models  of  new  aircraft 
(Section  5),  assuming  this  standard  becomes  a  contractual  requirement.  Thirdly, 
models  will  be  available  for  developing  derivatives  of  the  aircraft  and  for  research 
purposes. 

7.1  Location  of  the  Center;  Contractual  Arrangements 

The  Finite  Element  Model  Center  will  be  located  in  the  Flight  Dynamics  Direc¬ 
torate,  Wright  Laboratory,  Wright- Patterson  AFB,  Ohio.  The  Model  Center  could 
be  established  as  a  separate  organization  or  it  could  be  integrated  into  the  Aerospace 
Structures  Information  Analysis  Center  (ASIAC).  If  organized  separately,  the  Center 
would  be  a  contractor-operated  government  facility.  Integration  with  ASIAC  would 
offer  the  following  advantages: 

•  The  technical  skills  required  for  ASIAC  engineers  are  very  similar  to  those 
required  for  the  Model  Center. 

•  ASIAC  routinely  receives  finite  element  models  or  information  about  models, 
and  also  receives  requests  for  models. 

•  The  ASIAC  newsletter  could  be  used  as  a  publicity  medium  for  the  Center. 

•  A  single  contract  could  cover  both  activities. 

There  would  be  some  potential  disadvantages,  however: 

•  If  it  were  not  identified  by  a  separate  organizational  name  (the  Model  Center), 
but  only  as  an  ASIAC  task,  it  could  lose  visibility. 

•  Personnel  charged  with  working  on  Model  Center  tasks  could  be  diverted  to 
other  ASIAC  tasks. 

•  Cooperation  with  the  other  anticipated  auxiliary  centers  (discussed  below)  would 
be  more  difficult  if  the  center  were  not  autonomous. 


No  recommendation  is  made  at  this  time  as  to  whether  the  Model  Center  should 
be  part  of  ASIAC,  since  this  issue  hinges  on  so  many  factors  that  are  beyond  the 
technical  considerations  covered  in  this  report. 

7.1.1  Auxiliary  Centers 

Auxiliary  Centers  may  be  established  at  other  Air  Force  Bases  also.  These  would  be 
independent  operations,  separately  funded  and  operated.  The  organizations  selected 
below  all  provide  support  for  particular  aircraft  (with  the  exception  of  the  Armament 
Laboratory).  They  are  most  cognizant  of  the  current  status  of  their  particular  aircraft, 
and  are  in  contact  with  the  contractor  that  built  the  aircraft.  They  would  have  their 
own  copy  of  FEM-X,  maintain  their  own  database,  and  provide  their  own  funding  and 
facilities.  The  costs  associated  with  each  auxiliary  center  would  be  minimal,  since 
most  of  them  would  likely  have  a  suitable  workstation  available,  or  could  obtain  one 
at  minimal  cost.  An  existing  engineer  with  finite  element  skills  could  be  trained  in 
the  use  of  FEM-X  and  could  take  responsibility  for  the  auxiliary  Center.  The  main 
Center’s  primary  engineer  could  visit  each  establishment  for  about  a  week  and  provide 
setup,  training,  and  publicity. 

The  auxiliary  centers  are  not  envisaged  as  full  replicas  of  the  main  Center.  They 
would  not  engage  in  acquisition  of  models  except  for  their  particular  aircraft,  nor 
would  they  generally  distribute  their  models.  They  would  keep  contact  with  the 
main  Center  and  would  feed  their  new  models  or  updates  to  the  main  Center.  Com¬ 
munication  would  be  handled  primarily  by  electronic  mail. 

Possible  locations  of  auxiliary  centers  are  as  follows: 


Site 

Organization 

Specialty 

Eglin  AFB 

Air  Force  Armament  Laboratory 

Hill  AFB 

Ogden  Air  Logistics  Center 

F-4,  F-16 

Kelly  AFB 

San  Antonio  Air  Logistics  Center 

C-5A,  C-5B, 

C-9,  C-17, 

F-5 

McClellan  AFB 

Sacramento  Air  Logistics  Center 

A-7,  A-10, 

F-117A, 

F/FB/EF-111 

Robins  AFB 

Warner  Robins  Air  Logistics  Center 

F-15,  C-130,  C-141 

Tinker  AFB 

Oklahoma  City  Air  Logistics  Center 

B-1B,  B-2A,  B-52G/H 

It  is  anticipated  that  the  Armament  Laboratory  at  Eglin  AFB  and  the  organizations 
at  Wright-Patterson  AFB  will  ordinarily  be  users  of  the  models  maintained  at  the 
AFLC  organizations  and  that  any  models  developed  or  modified  by  these  research  or¬ 
ganizations  will  be  of  interest  primarily  to  specialized  users.  As  a  secondary  goal,  the 
center  will  attempt  to  collect  and  maintain  such  research  models  and  at  a  minimum 
will  try  to  track  and  be  aware  of  the  existence  of  these  models. 
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7.2  Operating  Procedures 

The  following  sections  outline  the  procedures  that  would  be  followed  in  the  daily 
operation  of  the  center,  as  well  as  the  initial  startup  period. 

7.2.1  Acceptance  of  Models 

Section  5  of  this  report  presents  a  proposed  set  of  standards  for  delivery  of  finite 
element  models  by  contractors  who  are  building  aircraft  for  the  Air  Force.  It  is 
hoped  that  such  a  set  of  standards  will  be  adopted  as  a  contractual  requirement  for 
new  aircraft.  As  these  standards  begin  to  take  effect  (which  will  take  some  time), 
the  Center  will  be  called  upon  to  assist  the  SPO’s  in  enforcing  the  standards  and 
in  actually  taking  delivery  of  the  models.  In  order  to  fulfill  this  function,  the  finite 
element  analyst  assigned  to  the  Center  will  have  to  be  thoroughly  familiar  with  the 
standard  and  will  have  to  document  his  efforts  on  behalf  of  the  SPO. 

The  Center’s  activities  will  not  be  confined  to  models  that  are  being  accepted 
on  behalf  of  SPO’s,  however.  The  Center  will  also  actively  seek  models  from  other 
sources:  from  within  the  Flight  Dynamics  Laboratory,  from  other  Air  Force  organiza¬ 
tions,  from  contractors,  and  elsewhere.  The  Center  will  of  course  be  unable  to  impose 
any  “delivery  standards”  on  these  organizations  but  will  in  most  cases  have  to  take 
what  it  can  get.  In  the  process  of  seeking  out  models  and  associated  documentation, 
the  Center’s  finite  element  analyst  will  therefore  be  called  upon  to  exercise  diplomatic 
and  public  relations  skills  in  addition  to  technical  skills. 

Electronic  mail  has  become  very  common  as  a  means  of  communication  among 
computer  users,  and  this  will  be  the  preferred  communication  medium  for  the  Center. 
All  that  is  necessary  is  to  obtain  an  official  e-mail  address  which  is  an  administrative 
task.  Wright-Patterson  has  the  required  network  facilities  for  world-wide  e-mail.  The 
Center  will  also  be  prepared  to  accept  models  in  various  tape  formats.  For  this 
purpose,  accounts  will  be  required  on  other  computers  on  the  Base  so  that  tapes  of 
various  kinds  can  be  read  and  the  files  transferred  over  the  local  network. 


7.2.2  Validation  of  Models 

The  importance  of  validation  will  be  difficult  to  overestimate.  The  Center’s  reputation 
and  credibility  would  suffer  mightily  if  ever  a  model  that  had  been  distributed  by  the 
Center,  with  its  stamp  of  approval,  were  found  to  be  defective  and  led  to  erroneous 
results,  wasted  time,  or  perhaps  even  to  faulty  structural  design  decisions.  (However, 
the  Center  may  choose  to  distribute  unverified  models  in  special  circumstances,  clearly 
marked  “as  is”  by  means  of  comments  included  both  in  the  text  that  is  delivered  with 
the  model  and  in  the  bulk  data.) 

Again  the  mode  of  operation  will  be  different  depending  on  whether  the  Center  is 
acting  on  behalf  of  a  SPO  in  accepting  new  finite  element  models  from  a  contractor, 
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or  accepting  a  model  that  the  Center  has  actively  solicited.  In  the  former  case,  the 
burden  lies  on  the  contractor  to  demonstrate  that  the  delivery  requirements,  including 
evidence  of  validation,  have  been  met.  The  Center’s  obligation  in  this  case  is  to  verify 
to  the  SPO  that  the  requirements  are  being  met,  both  through  documentation  and 
independent  validation  exercises  performed  on  the  models  by  the  Center. 

When  solicited  models  are  accepted  by  the  Center,  validation  will  be  especially 
important  because  the  organization  providing  the  model  will  typically  not  be  under 
any  obligation  to  the  Center,  and  may  not  be  responsive  to  requests  for  assistance  in 
understanding  the  model.  Thus  the  Center’s  analyst  will  have  to  have  the  skills  nec¬ 
essary  to  evaluate  a  model  without  any  outside  assistance.  Experience  and  judgement 
are  required  in  assessing  the  quality  of  solutions  produced  by  finite  element  software, 
and  the  limitations  of  a  model,  particularly  with  respect  to  its  frequency  bandwidth 
in  dynamic  analysis. 

7.2.3  Delivery  of  Models 

The  first  consideration  in  processing  a  request  for  delivery  of  a  model  is  the  re¬ 
questor’s  need  to  know.  Elaborate  administrative  procedures  will  not  be  required, 
since  distribution  of  Classified  models  is  not  anticipated.  A  letter  from  the  request¬ 
ing  organization  should  suffice. 

In  most  cases,  distribution  will  consist  of  an  ASCII  bulk  data  file  along  with 
supporting  documentation,  also  in  an  ASCII  file.  These  can  both  be  obtained  as 
output  from  FEM-X.  Transmission  can  be  accomplished  most  easily  via  e-mail,  but 
tapes  can  be  written  instead. 

A  record  will  be  kept  of  all  distributions  as  well  as  acceptance  of  new  models. 
This  can  be  done  using  a  modest  database  or  journal  file  on  the  Center’s  workstation. 

7.3  Computer  Hardware  Requirements 

Section  6  discussed  the  computer  hardware  and  software  environment  required  to  run 
FEM-X.  Two  options  are  possible  for  the  Center.  The  first  would  be  a  minimal 
configuration  using  an  X  Terminal  to  access  a  remote  machine  on  which  FEM-X  was 
installed.  At  least  40Mb  of  disk  space  would  be  required  on  the  remote  machine. 

The  second  option  would  have  a  dedicated  workstation  with  a  300-Mb  disk,  with 
FEM-X  installed  locally.  A  standard  19-in  black-and-white  monitor  would  be  suffi¬ 
cient  -  color  would  be  unnecessary.  This  is  the  preferred  option  for  several  reasons: 

1.  A  low-end  workstation  docs  not  cost  much  more  than  an  X  Terminal.1 

'For  example,  CSA  recently  obtained  two  Sun  386i  model  150  workstations.  They  are  somewhat 
out  of  date,  but  they  provide  local  processing  in  addition  to  X  server  functions  at  a  price  that  was 
less  than  the  price  of  a  new  X  Terminal. 
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2.  Computer  Center  personnel  sometimes  purge  user  files  on  the  machines  that 
they  control.  This  would  not  be  a  problem  with  a  dedicated  machine  under 
complete  control  of  the  Center. 

3.  The  Center  would  not  be  vulnerable  to  network  outages. 

A  printer  would  be  desirable  and  has  been  included  in  the  cost  figures  given  below. 
This  option  might  be  skipped  if  a  printer  were  available  on  the  network  at  a  location 
convenient  to  the  Center.  A  scanner  would  also  be  useful  but  has  not  been  included  in 
the  cost  figures.  For  one  thing,  we  are  not  aware  of  scanning  hardware  and  software 
that  is  compatible  with  Unix.  Access  to  scanners  elsewhere  on  the  Base  may  be 
possible. 

7.4  Publicity 

If  the  Center  is  to  achieve  its  potential,  it  will  have  to  be  publicized.  A  brochure 
will  be  prepared  that  explains  the  functions  of  the  Center  to  potential  users.  The 
brochure  can  be  prepared  inexpensively  using  a  desk-top  publishing  package  running 
on  the  Center’s  workstation,  or  at  the  Contractor’s  home  facility.  It  should  be  printed 
professionally  on  high-quality  paper. 

Word  of  mouth  will  be  an  important  means  of  publicity.  FIBR  personnel  can  assist 
in  informing  their  colleagues  in  various  Air  Force  organizations  about  the  Center’s 
services. 

7.5  Phasing  in  the  Center 

There  will  be  a  startup  or  phase-in  period  for  the  C  iter.  During  this  period  of 
perhaps  a  month,  it  is  anticipated  that  an  engineer  fron  .he  Contractor’s  organization 
would  work  on-site.  He  or  she  would  be  responsible  for: 

1.  Hiring  a  full-time  engineer  and  a  part-time  secretary. 

2.  Procuring  and  setting  up  the  workstation. 

3.  Installing  FEM-X  and  other  software. 

4.  Training  the  engineer  in  the  use  of  FEM-X. 

5.  Doing  some  initial  solicitation  and  gathering  of  models. 

6.  Publicizing  the  Center. 

Resources  should  be  allocated  for  maintenance  and  enhancement  of  FEM-X.  This 
is  a  normal  part  of  any  software  project  of  this  size.  These  activities  would  probably 
be  performed  at  the  contractor’s  home  office  and  not  at  the  Center.  Distribution  of 
FEM-X,  if  authorized  by  the  Air  Force,  would  also  require  a  small  part  of  the  budget. 
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7.6  Staffing  Requirements 

The  work  involved  in  operating  the  Center  may  be  broken  down  as  follows: 

1.  Coordinating  with  engineers  in  other  organizations:  soliciting  models  and  sup¬ 
porting  documentation,  answering  inquiries,  distributing  models  and  documen¬ 
tation,  setting  up  auxiliary  centers  (as  described  above),  and  distributing  copies 
ofFEM-X. 

2.  Performing  finite  element  analysis  work,  (e.q.,  modeling  structural  changes,  new 
loads,  etc.). 

3.  Managing  the  local  workstation. 

4.  Writing  reports  and  doing  other  paperwork. 

Items  1  and  2  require  an  engineering  professional.  There  is  some  clerical  work  entailed 
in  item  4.  Managing  a  workstation  is  not  particularly  difficult;  a  clerical  person  could 
be  taught  to  do  tasks  such  as  backup.  The  workstation  might  be  set  up  under 
the  supervision  of  an  expert  from  the  Computer  Center  or  from  the  contractor’s 
organization,  who  could  provide  some  training  in  the  use  of  the  X  Window  System. 

In  light  of  these  considerations,  the  staffing  proposed  for  the  Center  consists  of 
a  full-time  finite-element  analyst  and  a  part-time  secretary  (with  some  computer 
aptitude). 


7.7  Cost  of  Operation;  Government-Furnished  Equipment. 

Estimated  costs  for  establishing  and  maintaining  the  Finite  Element  Model  Center 
are  given  here.  It  is  assumed  that  space  and  office  furniture  for  the  Center  will  be 
provided  on-base  in  a  manner  similar  to  the  Aerospace  Structures  Information  and 
Analysis  Center  (ASIAC).  Following  are  the  estimated  costs,  fully  burdened. 

Government-furnished  equipment  includes  office  space  suitable  for  two  people  and 
a  workstation,  plus  office  equipment  (desks  and  chairs,  file  cabinets,  bookshelves, 
workstation  desk).  A  commercial  telephone  line  is  assumed;  a  base  phone  could  also 
be  installed. 


7.8  Security  Procedures 

It  is  not  anticipated  that  any  of  the  finite  element  models  in  the  model  center  will  be 
classified;  however,  some  information  may  be  sensitive  in  nature  and  precautions  will 
have  to  be  provided  for  appropriately  safeguarding  the  data.  The  tape  drive  specified 
in  the  computer  hardware  section  will  be  helpful  in  this  regard. 
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As  a  government  contractor  located  on  a  military  base,  Center  personnel  comply 
with  both  the  local  security  regulations  and  with  the  provisions  of  the  Industrial 
Security  Manual.  As  a  Visitor  Group  on  a  military  base,  all  personnel  of  the  center 
will  be  required  to  attend  the  security  briefings  scheduled  by  the  host  organization, 
in  addition  to  complying  with  the  security  provisions  of  the  contractor  organization. 
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Appendix  A:  Interview  Transcripts 


This  appendix  presents  interviews  that  were  conducted  with  six  Air  Force  organi¬ 
zations  and  one  NASA  organization.  The  following  organizations  were  surveyed: 
ASD/ENFS  (WPAFB),  Eglin  AFB,  4950th  Test  Wing  (WPAFB),  Wamer-Robbins 
ALC,  Hill  AFB,  Sacramento  ALC  (McClellan  AFB),  and  NASA/Dryden.  One  tran¬ 
script  is  provided  for  each  organization,  following  a  standard  format. 

A.l  ASD/ENFS,  WPAFB 

Interviewer:  G.  Negaard  (in  person) 

Persons  interviewed:  Hugh  Griffis,  Robert  Moore 


Organizational  mission: 

Review  contractors’  structural  analysis  including  finite  element  analysis.  Per¬ 
form  hardness  assessments,  look  at  flutter  problems. 


Organizational  capability: 

Personnel:  Two  people  in  the  vulnerability  group,  three  in  the  flutter  group. 
Other  ASD  structures  personnel  are  scattered  among  the  SPO’s. 

Expertise:  Novice  to  intermediate,  able  to  understand  contractors’  work  and 
perform  some  FE  analysis. 

Equipment:  CDC  and  VAX,  Tektronix  terminals;  PATRAN,  NASTRAN. 
They  have  developed  the  DATANET  code  which  uses  FASTGEN,  MOVIE.BYU, 
and  TRACELINKS  to  do  animation  of  large  models.  They  are  getting 
NAVGRAF  (a  new  package  which  encompasses  graphic  pre-processing,  COS¬ 
MIC  NASTRAN,  and  graphic  post-processing).  They  are  having  a  ballistics 
and  laser  vulnerability  capability  put  into  ASTROS. 


Organizational  use  of  finite  element  models: 

They  review  contractors’  analysis,  check  some  of  it. 

Use  NASTRAN  and  thermal  codes.  Perform  1-D  thermal  analysis  to  check  for 
exceeding  elastic  limits.  Panel  analysis  for  overpressures. 

Did  T-46  flutter  analysis  using  NASTRAN  to  get  natural  frequencies  and  modes 
shapes,  then  FACES  for  flutter  analysis. 
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Acquisition  methods: 

How  are  models  obtained? 

Via  S.O.W.  where  possible,  otherwise  by  “begging,  borrowing,  or  stealing”. 
How  are  such  models  verified  and  understood? 

By  contractors  only,  to  any  real  degree. 

How  are  they  archived  and  retrieved? 

Not  really  archived  at  all. 

Lessons  learned  in  this  area? 

Need  a  system  to  obtain  and  keep  models. 

Existing  or  potential  needs  for  FE  models: 

F-15E  model  coming.  Will  be  in  McDonnell-Douglas  format,  will  have  to  be 
converted  to  NASTRAN. 

Have  an  F-15C/D  model  in  McDonnell-Douglas  format,  with  numerous  errors. 
Have  a  need  for  the  dual  role  fighter  model  (F-16E?) 

HALE  (High  Altitude  Long  Endurance)  aircraft  coming  up 

Awareness  of  FE  models  developed  by  contractors: 

GLCM  (Ground- Launched  Cruise  Missile).  Launcher,  truck,  and  trailer. 

B-52  (on  paper  . . .  needs  tying  in) 

KC-135  (on  paper  . . .  needs  tying  in) 

Response  to  the  idea  of  a  model  center: 

They  favor  the  idea,  suggest  that  AFWAL  draft  a  letter  to  each  Program  Office 
asking  them  for  a  model  with  necessary  documentation. 
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How  they  would  like  to  see  a  Model  Center  work: 

They  would  like  someone  to  take  paper  listing  of  models,  put  them  up,  verify, 
and  make  them  available  as  needed. 

There  is  no  real  need  for  quick  response.  A  few  days  or  weeks  is  quick  enough 
for  their  needs. 

Estimate  of  funds  or  time  that  might  be  saved  if  a  Model  Center  existed: 

Paraphrasing:  “When  you  have  to  go  to  the  contractor  for  a  model,  it’s  going 
to  take  a  year  or  more,  so  if  something  has  to  be  done  in  a  timely  manner,  it 
doesn’t  get  done.  Having  a  model  available  would  allow  analysis  of  problems 
that  often  are  not  attempted  due  to  time  constraints.” 

As  for  funds,  the  F-15C/D  model  was  obtained  for  $50,000  from  the  contractor. 
This  procurement  was  tacked  on  to  a  larger  contract.  The  model  was  actually 
“free”;  it  was  the  documentation  that  cost  $50,000.  However,  if  the  contractor 
were  asked  to  create  a  model  it  would  cost  at  least  $500,000. 


A. 2  Eglin  AFB 

Interviewer:  G.  Negaard  (telephone) 

Persons  interviewed:  Jim  Robinson,  Wayne  Ingraham 
Phone  number:  AV  88-872-2748/3017 

Organizational  Mission: 

Store  certification  for  aircraft  and  stores. 

Organizational  capability: 

Personnel:  Three  people  in  flutter  analysis,  three  in  loads. 

Expertise:  Mostly  in  flutter.  Loads  people  have  two  entry  level  engineers,  one 
more  experienced  analyst. 

Equipment:  Cyber  176  mainframe,  MSC/NASTRAN  only. 

Organizational  use  of  finite  element  models: 

To  analyze  flutter  with  stores. 
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Acquisition  methods: 

How  are  models  obtained? 

They  have  usually  gone  to  contractors  for  models.  They  do  not  do  any 
modelling  of  their  own.  They  typically  use  stick  models  for  dynamic  anal¬ 
ysis. 

How  are  such  models  verified  and  understood? 

Apply  allowable  loads.  If  wing  torsion  or  wing  bending  exceed  allowable 
limits  at  any  station,  they  go  back  to  the  contractor  for  additional  analysis. 

How  are  they  archived  and  retrieved? 

They  have  no  system. 

Existing  or  potential  needs  for  FE  models: 

F-lll  (future) 

A- 10,  F-4  flutter  models 

F-15  A/B/C/D  models  (now  on  hand) 

Getting  F-16  model  from  GD  in  a  month  -  primarily  wing,  fuselage  and 
empennage  represented  by  gross  elements.  The  model  will  have  100-200  ele¬ 
ments  for  dynamic  analysis. 

Awareness  of  FE  models  developed  by  contractors: 

F-15  models 
F-16  model 

Response  to  the  idea  of  a  model  center: 

No  response;  not  knowledgeable. 

Estimate  of  funds  or  time  that  might  be  saved  if  a  Model  Center  existed: 
They  had  no  idea  but  felt  they  could  benefit. 
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A.3  4950th  Test  Wing 

Interviewer:  G.  Negaard  (in  person) 

Persons  interviewed:  Lloyd  Matson,  George  Perley 


Organizational  Mission: 

Design  and  build  modifications  to  existing  aircraft.  They  are  presently  convert¬ 
ing  several  old  commercial  707’s  to  C-18’s. 

Organizational  capability: 

Personnel:  Ter.  people 

Expertise:  Static,  dynamic,  and  flutter  analysis.  Considerable  expertise,  rang¬ 
ing  from  a  few  years  to  ten  or  more. 

Equipment:  Cray,  CDC,  and  VAX,  Tektronix  terminals;  PATRAN,  NAS- 
TRAN.  Access  to  MSC/NASTRAN  via  Cybernet.  One  Evans  &  Sutherland 
graphics  system.  They  have  three  VAXes  of  their  own,  and  four  or  five  Mi- 
croVAXes.  They  are  going  out  for  a  CAD/CAM/  CAE  system  -  Sim,  Apollo, 
or  Intergraph. 

Organizational  use  of  finite  element  models: 

Usually  to  check  static  strength  for  aircraft  modifications  such  as  radomes  or 
equipment  racks.  They  are  also  working  on  a  project  called  ECCM/ARTB 
(Electronic  Countermeasures/Advanced  Radar  Test  Bed)  which  requires  cutting 
holes  in  the  top  of  a  C-141  fuselage  to  mount  radomes. 


Acquisition  methods: 

How  are  models  obtained? 

They  often  build  their  own  models  but  sometimes  go  out  on  contract. 
Rockwell,  for  example,  just  made  them  a  model  of  a  450-inch  fuselage 
section  of  a  C-141. 

How  are  such  models  verified  and  understood? 

By  comparing  to  existing  models  or  similar  data.  Also  with  hand  calcu¬ 
lations.  For  example,  the  Rockwell  C-141  fuselage  model  showed  negative 
margins  of  safety  In  several  places,  and  the  original  Lockheed  analysis  did 
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not.  However,  these  points  are  places  where  the  C-141  has  had  fatigue 
problems,  which  helped  verify  the  Rockwell  model. 


How  are  they  archived  and  retrieved? 

Cards,  tape,  hard-copy  printout.  No  system  for  permanent  storage. 
Lessons  learned  in  this  area? 

They  need  a  system  to  catalog  and  keep  track  of  models. 

Existing  or  potential  needs  for  FE  models: 

C-18  (Boeing  707)  fuselage  to  aid  in  fatigue  analysis 

C-135 

C-141 

T-39 

A-37 

A-7D 

Awareness  of  FE  models  developed  by  contractors: 

C-141  done  by  Rockwell 

Response  to  the  idea  of  a  model  center: 

They  favor  the  idea,  if  the  procedure  can  be  and  painless. 

How  they  would  like  to  see  a  Model  Center  work: 

They  would  like  to  be  able  to  pick  up  the  phone,  interrogate  a  database,  pull 
up  *  pictures  of  models,  then  order  the  components  decided  upon. 

Estimate  of  funds  or  time  that  might  be  saved  if  a  Model  Center  existed: 

They  have  no  idea,  because  their  needs  are  so  special  that  they  generally  have  to 
start  from  scratch  and  build  their  own  models.  (Note:  the  4950th  was  unaware 
of  the  C-141  COSMIC  NASTRAN  model  that  Warner- Robbins  has.  We  gave 
them  a  contact  to  call  there.) 
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A. 4  Warner-Robbins  ALC 


Interviewer:  G.  Negaard  (telephone) 

Persons  interviewed:  Robert  Wade,  Lt  Randy  Jansen 
Phone  number:  AV  88-468-2525 

Organizational  Mission: 

Depot  maintenance  for  C-141,  C-130,  F-15,  and  H-53  aircraft. 

Organizational  capability: 

Personnel:  Seven  engineers  and  a  manager. 

Expertise:  Mostly  static  analysis. 

Equipment:  Dedicated  VAX-11/785,  Tektronix  terminals, 

MSC/NASTRAN,  Supertab. 

Organizational  use  of  finite  element  models: 

Usually  to  check  static  strength  for  aircraft  modifications  or  repairs.  They  use 
large  models  to  get  internal  loads  which  are  then  used  for  stress  analysis  on 
small  parts.  They  also  look  at  fatigue  problems. 

Acquisition  methods: 

How  are  models  obtained? 

They  usually  build  the  component  models  they  need. 

How  are  such  models  verified  and  understood? 

“As  best  one  can.”  Hand  calculations,  for  example. 

How  are  they  archived  and  retrieved? 

On  tapes  and  on  the  VAX. 

Existing  or  potential  needs  for  FE  models: 

They  have  C-130  and  C-141  COSMIC  NASTRAN  models. 

They  are  getting  an  F-15E  model  in  MacAir  format;  need  to  convert  it  to 
NASTRAN. 
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Awareness  of  FE  models  developed  by  contractors: 

F-15  Models 

Response  to  the  idea  of  a  model  center: 

Not  much  need  for  lar^e  models  except  to  get  loads  for  components.  For  small 
models,  they  go  straight  to  the  drawings,  work  off  the  drawings  as  needed,  or 
take  measurements  from  parts. 


How  they  would  like  to  see  a  Model  Center  work: 
Moderate  interest,  not  sure  how  they  would  benefit. 


Estimate  of  funds  or  time  that  might  be  saved  if  a  Model  Center  existed: 
No  idea. 

A. 5  Hill  AFB  (MMSR,  MMAR,  MMMDR,  MMIR) 

Interviewer:  M.  James  (in  person) 

Persons  interviewed:  Bret  Hamblin,  Tim  Sorensen,  Bruce  Burgon 
Phone  number:  (801)  777-7072 


Organizational  Mission: 

Perform  fatigue  analysis  on  various  parts  of  the  F-4  and  F-16  aircraft.  Hill  AFB 
is  the  central  depository  for  all  aircraft  landing  gear  technology  throughout  the 
Air  Force. 


Organizational  capability: 

Personnel:  MMSR:  8  civilian,  3  military;  MMAR:  10  civilian,  2  military; 
MMMDR:  4  civilian,  1  military 

Expertise:  Novices  in  the  use  of  both  NASTRAN  and  CRACKS  85.  The 
longest  experience  of  any  individual  is  two  years.  Contractors  supply  the  nec¬ 
essary  expertise,  as  a  rule. 

Equipment:  Two  clustered  VAX-1 1/785’s,  Tektronix  4109  and  4129  terminals. 
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Organizational  use  of  finite  element  models: 


They  develop  finite  element  models  for  fatigue  analysis,  primarily,  but  also  do 
some  design  and  repair  work.  The  models  are  usually  created  in-house  with 
some  assistance  from  contractors  (BYU  and  General  Dynamics),  or  by  outright 
purchase  (F-16  from  General  Dynamics). 

Acquisition  methods: 

How  are  models  obtained? 

Purchased  from  manufacturer  or  created  in-house. 

How  are  such  models  verified  and  understood? 

No  verification  yet! 

How  are  they  archived  and  retrieved? 

Models  are  stored  on  VAX  disks  and  backed  up  on  magnetic  tape. 

Lessons  learned  in  this  area? 

Disk  crashes  have  resulted  in  a  loss  of  time  and  effort.  No  crash  has  been 
bad  enough  to  endanger  the  models  totally  but  a  few  days’  worth  of  work 
was  lost  ac  times! 


Existing  or  potential  needs  for  FE  models: 

F-16  and  F-4  aircraft  for  fatigue  analysis.  Hill  AFB  is  the  depository  for  all 
aircraft  landing  gear,  including  models. 


Awareness  of  FE  models  developed  by  contractors: 

MacAir  has  an  F-4  modol. 

General  Dynamics  has  a  complete  model  of  the  F-16.  (They  are  rumored  to 
have  an  F-16E  model  as  well.) 

Response  to  the  idea  of  a  model  center: 

They  are  very  receptive.  They  do  express  a  concern  that  the  repository  may 
get  tangled  in  the  typical  government  red  tape,  however.  It  must  be  run  by 
contractors  and  it  must  be  “user-friendly.” 
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How  they  would  like  to  see  a  Model  Center  work: 

A  pictorial  display  of  the  model  using  an  MSC/NASTRAN  database  of 
superelements  of  the  entire  aircraft.  All  models  must  be  completely  verified 
to  be  worth  while! 


Estimate  of  funds  or  time  that  might  be  saved  if  a  Model  Center  existed: 

A  lot  of  money  may  be  saved  by  ensuring  that  all  models  being  used  through¬ 
out  the  Air  Force  are  keyed  to  the  current  revision  of  the  aircraft.  The  other 
armed  services  should  be  consulted  regarding  models  they  have  so  as  to  reduce 
redundant  efforts  in  model  building  and  verification. 


A. 6  Sacramento  ALC 

Interviewer:  W.  Gibson  (in  person) 

Persons  interviewed:  Mr.  Sal  Alestra 
Phone  number:  (916)  643-5300 

Organizational  Mission: 

F-lll  and  A-10  »>rcraft.  Mostly  stress  analysis  with  concentration  on  durability 
and  damage  tolerance  assessments. 

Organizational  capability: 

Personnel:  Five  engineers  and  a  manager. 

Expertise:  Mostly  static  analysis. 

Equipment:  VAX-11/780.  MSC/NASTRAN,  GIFTS. 

Organizational  use  of  finite  element  models: 

They  use  F-lll  and  A-10  models  primarily  for  analysis  of  damage  and  corrosion. 
However,  due  to  manpower  problems,  they  are  largely  in  a  reactive  mode. 

Acquisition  methods: 

How  are  models  obtained? 

They  “found”  three  A-10  models. 
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Are  paying  for  two  F-lll  models;  will  procure  six  more. 

Model  deliver  will  be  a  future  contractual  requirement. 

How  are  such  models  verified  and  understood? 

GD  provides  them  with  GIFTS  steering  files.  They  use  GIFTS  interactive 
viewing  commands  to  gain  understanding  of  models. 

How  are  they  archived  and  retrieved? 

On  the  VAX,  with  backup  tapes. 

Existing  or  potential  needs  for  FE  models: 

They  are  getting  new  F-lll  models  from  GD. 

Awareness  of  FE  models  developed  by  contractors: 

Strong  awareness  of  F-lll  and  A-10  models  developed  by  GD 


Response  to  the  idea  of  a  model  center: 

They  do  not  favor  the  idea.  They  say  they  are  the  only  Air  Force  organization 
doing  analysis  on  the  F-lll  aircraft.1  Therefore  they  should  be  in  charge  of  all 
F-lll  models.  They  see  requirements  for  them  to  send  models  to  the  Center  as 
an  additional  burden  that  would  detract  from  their  main  mission. 


How  they  would  like  to  see  a  Model  Center  work: 

Use  of  COSMIC  NASTRAN  instead  of  MSC/NASTRAN  would  be  a  “kiss  of 
death”  for  the  Center. 


A. 7  NASA/Dryden 

Interviewer:  M.  James  (telephone) 

Persons  interviewed:  Alan  Carter,  Larry  Shuster 
Phone  Number:  (805)  258-3311  ext  3919 

'However,  Warner- Robbins  personnel  expressed  an  interest  in  an  F-lll  model.  See  section  A. 4. 


All 


Organizational  Mission: 


Maintain  finite  element  models  of  aircraft  at  NASA/Diyden  and  update  those 
models  when  changes  occur  to  either  the  structure  and  the  stores. 

Organizational  Capability: 

Expertise:  Several  experts  in  the  field  of  structural  analysis  using  codes  such  as 
COSMIC  and  MSC/NASTRAN. 

Equipment:  VAX’s  and  an  ELXI  multiple  processor  system. 


Organizational  use  of  finite  element  models: 

On-site  development  of  finite  element  models  to  be  used  for  stress,  dynamic  and 
loads  analysis.  Most  models  are  made  in-house  but  a  few  have  been  procured 
from  contractors. 


Acquisition  Method: 

How  are  models  obtained? 

Made  in-house  usually. 

How  are  such  models  verified  and  understood? 

In-house  models  are  verified  as  they  are  made.  The  modeler  must  trust  the 
drawings  and  other  items  used  to  make  models.  The  understanding  of  the 
models  is  very  great  because  the  author  of  the  model  is  at  NASA/Dryden. 

How  are  they  archived  and  retrieved? 

The  models  are  constructed  and  placed  in  storage  on  the  computer  system. 
Paper  writeups  are  available  to  identify  models. 

Lessons  learned  in  this  area? 

The  models  must  be  backed  up  on  computer  tape  to  ensure  that  they  are 
secure  from  loss.  No  problems  otherwise. 

Existing  or  potential  needs  for  FE  models: 

NASA/Dryden  has  models  of  the  Bl-A  and  the  X29  forward  swept-wing  aircraft. 
They  see  no  need  for  other  models  as  yet  but  as  aircraft  are  added  to  the 
inventory  at  Dryden  they  will  either  acquire  or  build  models  of  those  aircraft. 
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Awareness  of  FE  models  developed  by  contractors: 

NASA/Dryden  has  little  contact  with  outside  contractors  in  the  modeling  area 
except  for  COSMIC  NASTRAN  colloquia.  Rockwell  provided  the  Bl-A  model 
at  Dryden  and  should  have  a  Bl-B  model. 

Response  to  the  idea  of  a  model  center: 

Larry  Shuster  seemed  pleased  to  hear  that  a  finite  element  model  center  is  being 
talked  about.  He  believes  that  the  center  would  be  a  major  step  forward  but 
the  problems  associated  with  the  center  could  be  great.  The  major  problem 
will  be  cooperation  from  all  the  organizations  involved. 

How  would  they  like  to  see  a  model  center  work: 

Not  sure  that  they  would  use  the  center  except  to  possibly  contribute  models 
to  the  center! 

Estimate  of  funds  or  time  that  might  be  saved  if  a  Model  Center  existed: 

Would  not  use  center  for  retrieval  of  models  but  may  participate  after  acceptance 
throughout  the  FEM  community. 


Appendix  B:  Mil  Standard  Requirements  for  Fi¬ 
nite  Element  Models 


1.  SCOPE 

1.1.  Scope.  This  standard  establishes  guidelines  and  requirements  for  the  devel¬ 
opment  and  delivery  of  a  finite  element  model  of  an  aircraft  structure. 

1.2.  Purpose.  The  purpose  of  this  standard  is  to  establish  uniform  practices  for 
finite  element  model  documentation,  to  ensure  the  inclusion  of  essential  information, 
and  to  establish  a  practice  of  maintaining  and  updating  the  models. 

1.3.  Application.  This  standard  may  be  applied  at  the  discretion  of  the  program 
manager  to  any  system  or  major  equipment  program  or  project.  When  this  standard 
is  applied  on  a  contract,  the  prime  contractor  may,  at  his  option,  or  as  specified  by 
the  Government,  impose  tailored  requirements  of  this  standard  on  subcontractors. 

1.4.  Implementation.  This  standard  is  intended  to  be  used  in  preparing  require¬ 
ments  for  inclusion  in  solicitation  documents  and  contract  work  statements  during 
the  development  of  an  airframe  for  a  particular  weapon  or  support  system.  Waivers 
or  deviations  shall  be  specified  in  the  contract  specifications  and  shall  have  specific 
Air  Force  approval  prior  to  commitment. 

1.5.  Tailoring.  The  Air  Force  will  make  the  decision  regarding  application  of  this 
standard  and  may  modify  or  tailor  task  statements  to  suit  system  needs.  Tailoring 
takes  the  form  of  deletion,  alteration  or  addition  to  the  task  statements.  In  tailoring 
the  tasks,  the  depth  of  detail  and  level  of  effort  required,  and  the  intermediate  and 
output  engineering  data  expected  must  be  defined.  Subsequent  tailoring  may  be  done 
by  the  contractor  and  the  Government  during  contract  negotiations.  The  agreement 
reached  shall  be  reflected  in  the  resultant  contract. 

2.  REFERENCED  DOCUMENTS. 

Military  Specifications: 

MIL-A-87221  General  Specification  for  Aircraft 

Structures 

Military  Standards: 

MIL-STD-483  Configuration  Management  Practices  for 

Systems,  Equipment,  Maintenance  and 

Computer  Software 

MIL-STD-1521  Technical  Review  and  Audit  for  Systems, 

Equipment  and  Computer  Software 

MIL-STD-1587  Materials  and  Processes  Requirements  for 

Air  Force  Weapon  Systems 
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Handbooks: 


MIL-HDBK-5  Metallic  Materials  and  Elements  for 

Aerospace  Vehicle  Structures 
MIL-HDBK-17  Plastics  for  Aerospace  Vehicles 

MIL-HDBK-23  Structural  Sandwich  Composites 

Air  Force  Systems  Command  Handbooks: 


DH-1-0 

General 

DH-1-1 

General  Index  and  References 

DH-1-2 

General  Design  Factors 

DH-2-0 

Aeronautical  Systems 

DH-2-1 

Airframe 

DH-2-7 

System  Survivability  * 

3.  DEFINITIONS. 

3.1.  Airframe.  The  complete  aircraft  structure,  including  the  fuselage,  wing, 
empennage,  landing  gear,  control  systems  and  surfaces,  engine  mounts,  structural 
operating  mechanisms,  and  other  components  as  specified  in  the  contract  specifica¬ 
tions. 

3.2.  Structural  Operating  Mechanisms.  Those  operating,  articulating,  and  con¬ 
trol  mechanisms  which  transmit  structural  forces  during  actuation  and  movement  of 
structural  surfaces  and  elements. 

3.3.  Finite  Element  Model.  A  structural  model,  wherein  the  distributed  physical 
properties  of  a  structure  are  represented  by  a  finite  number  of  idealized  substructures 
or  elements  that  are  interconnected  at  a  finite  number  of  points. 


4.  GENERAL  REQUIREMENTS. 

The  contractor  shall  create  and  submit  a  finite  element  model  of  the  airframe 
capable  of  producing  detailed  analyses  of  the  major  components  of  the  structure  to 
demonstrate  load  paths  and  to  perform  stress  calculations  of  primary  and  secondary 
components.  The  finite  element  model  should  provide  the  capability  to  analyze  the 
airframe  under  both  symmetric  and  anti-symmetric  external  loads  and  to  generate 
internal  design  loads.  It  is  anticipated  that  this  finite  element  model  will  be  the  same 
model  used  by  the  contractor  to  perform  the  analytical  determination  of  the  struc¬ 
ture’s  ability  to  support  critical  loads  and  to  meet  the  specified  strength  requirements 
as  well  as  for  dynamic  analyses.  In  this  event,  the  stress  analysis  reports  and  other 
analysis  reports  will  form  part  of  the  supporting  documentation  for  the  model.  If  the 
contractor  has  not  used  the  model  for  this  purpose,  then  sufficient  documentation 
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must  be  accomplished  and  included  to  serve  to  validate  the  model.  For  each  model, 
a  complete  set  of  documentation  will  be  required. 


5.  DETAILED  MODEL  REQUIREMENTS. 

5.1.  The  contractor  shall  deliver  to  the  Air  Force  all  finite  element  models  that 
were  used  in  verifying  the  structural  integrity  of  the  aircraft,  in  its  final  configuration 
as  delivered  to  the  Air  Force. 

5.2.  Contractors  shall  not  be  required  to  use  any  particular  computer  software 
in  their  finite  element  analysis  work.  Models  shall  be  delivered  in  the  format  appro¬ 
priate  to  the  particular  software  that  was  used.  If  some  code  other  than  COSMIC 
NASTRAN  is  used  by  the  contractor  ,  a  translated  version  of  each  model  shall  also  be 
provided.  The  translated  version  will  conform  to  the  input  requirements  of  COSMIC 
NASTRAN  (specifically,  the  version  of  COSMIC  NASTRAN  current  at  the  time  of 
delivery). 


6.  DETAILED  DOCUMENTATION  REQUIREMENTS 

6.1.  For  each  model  delivered,  a  complete  set  of  documentation  is  required. 

6.2.  For  each  model,  the  name  and  configuration  of  the  aircraft  will  be  identified. 
A  key  diagram  showing  the  location  of  the  component  being  modeled  in  relation  to  the 
rest  of  the  model  will  be  included.  The  construction,  arrangement,  material,  location 
(by  coordinates)  of  load-carrying  members,  and  other  pertinent  data  shall  be  included. 
Adequate  sketches  shall  be  provided  so  as  to  minimize  the  necessity  of  referring  to 
detailed  drawings  of  the  structure.  Drawings  to  which  the  model  corresponds  will  be 
identified.  The  drawings  referenced  in  the  model  shall  be  provided  if  they  are  not 
otherwise  available  to  the  government. 

6.3.  Adequate  identification  of  all  aspects  of  the  finite  element  model  shall  be 
included  with  the  finite  element  model.  Documentation  shall  indicate,  individually 
or  by  groups,  what  part  of  the  structure  is  represented  by  the  nodes,  elements,  element 
properties,  and  materials.  Coordinate  systems  shall  be  defined  in  terms  of  the  primary 
aircraft  coordinate  system.  Applied  loads,  support  conditions,  and  rigid  elements  shall 
be  explained.  The  output  information  shall  include,  but  not  be  limited  to,  deflections, 
stresses,  element  forces,  and  restraint  forces.  Proprietary  information  should  be  so 
indicated. 

6.4.  The  documentation  will  include  a  brief  discussion  of  the  physical  phenomenon 
being  modeled.  The  fineness  or  coarseness  of  the  model  will  be  discussed.  The  use  of 
any  special  techniques  such  as  symmetry  (type  and  location)  will  be  documented.  A 
list  of  element  types  and  the  rationale  for  the  use  of  each  will  be  provided.  Smearing 
approximations  will  be  explained  wherever  they  have  been  used.  All  material  proper¬ 
ties  shall  be  explained  and  referred  to  appropriate  Mil  Standards,  and  reasons  given 
for  any  deviations.  Each  set  of  boundary  conditions  or  constraints  will  be  explained. 
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6.5.  The  contractor  shall  explain  how  the  model  was  validated.  This  discussion 
includes  diagnostic  messages  from  the  finite  element  code,  comparison  to  known  or 
expected  results,  and  reference  to  test  data  where  it  is  available. 

6.6.  Documentation  will  include  the  following: 

6.6.1.  Static  models.  An  e'cplanation  will  be  provided  for  each  set  of  loads,  in¬ 
cluding  the  category  (distributed  forces,  concentrated  forces,  gravity  loads,  prescribed 
displacements,  thermal  forces,  imposed  deformations  (strains),  centrifugal  loads,  or 
special  situations).  Where  load  sets  are  to  be  combined,  the  combined  sets  must  be 
documented.  Where  nonlinear  analysis  is  used,  information  specific  to  the  nonlin¬ 
ear  aspects  of  the  analysis  must  be  presented,  such  as  the  nature  of  the  nonlinearity 
(finite  displacements,  nonlinear  elasticity,  plasticity),  and  the  reason  why  non-linear 
behavior  was  expected.  Control  parameters  that  were  used  in  the  iterative  solution 
and  evidence  of  convergence  will  be  documented. 

6.6.2.  Dynamic  models.  Dynamic  models  include  undamped  normal  modes, 
damped  modes  (complex  eigenvalues),  transient  analysis,  steady-state  frequency  re¬ 
sponse  analysis,  and  random  analysis.  Documentation  will  include  the  frequency 
range  over  which  the  model  is  valid  and  the  reduction  process,  if  any,  that  was  used. 
This  may  include  subspace  iteration,  generalized  dynamic  reduction,  Guyan  reduc¬ 
tion,  or  Ritz  vectors.  In  the  case  of  Guyan  reduction,  an  explanation  of  the  analysis- 
set  degrees  of  freedom  shall  be  provided.  In  the  case  of  Ritz  vectors,  an  explanation 
of  the  static  loads  used  to  start  the  process  shall  be  provided.  Nonstructural  masses 
will  be  documented  and  explainer.  For  dynamic  response  analysis,  documentation 
shall  include  the  source  of  the  loading  and  the  way  in  which  its  frequency  distribution 
or  time  history  were  derived,  the  the  kind  of  damping  used  (viscous  or  structural) 
and  how  values  were  arrived  at.  For  either  transient  or  steady-state  analysis,  where 
modal  superposition  is  used,  the  frequency  at  which  modes  were  truncated  shall  be 
justified,  and  the  use  of  any  special  enhancement  techniques  such  as  residual  flexibility 
explained.  For  transient  analyses,  the  time  step  value  that  was  chosen  shall  be  jus¬ 
tified.  For  steady-state  frequency  response  analysis,  an  explanation  of  the  frequency 
increment  shall  be  provided. 

6.6.3.  Heat  Transfer  Analysis.  This  category  includes  linear  steady  state,  nonlin¬ 
ear  steady  state,  linear  transient,  and  non-linear  transient  analysis.  Documentation 
shall  include  derivation  of  the  material  properties  with  references  to  heat  sources 
and  sinks,  boundary  conditions,  analysis  type,  and  transfer  of  temperatures  to  static 
stress  analysis  models,  if  applicable. 

6.6.4.  Aeroelastic  Models.  Where  aeroelastic  analyses  are  performed,  the  aerody¬ 
namic  theory  employed  will  be  described.  The  lifting  surfaces  for  which  the  aerody¬ 
namics  being  modeled  shall  be  enumerated  and  described  physically.  Aerodynamic 
parameters  such  as  Mach  number  and  altitude  shall  be  listed.  The  kinds  of  force 
and  displacement  transformations  between  the  structural  grid  and  the  aerodynamic 
grid  shall  be  explained.  Provisions  for  rigid-body  modes  will  be  explained.  Where 
aeroservoelastic  analysis  is  employed  or  anticipated,  data  must  be  presented  in  a  state 
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space  formulation. 

6.6.5.  Special  Analysis  Types.  A  full  explanation  of  the  coupling  method  used 
for  any  special  analysis  types  such  as  combined  structure-control  system  analysis  or 
fluid-structure  interaction  shall  be  provided. 
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